You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by ocket 8888 <oc...@gmail.com> on 2019/11/22 16:44:08 UTC

Deprecate /hwinfo

The /hwinfo endpoint doesn't appear to serve any real purpose (anymore?).
There's no way to insert data through the API so it can only even show
anything if the database is manually manipulated.

This is not to be confused with /hwinfo/dtdata, which I believe we already
agreed to deprecate (?).

There's currently a deprecation notice in the documentation, but not in the
API - and that deprecation was never brought up here. So is there anyone
that objects to making this deprecation official? I'm already working on a
rewrite to Go, so I can add the API deprecation warning at the same time.

Re: Deprecate /hwinfo

Posted by ocket 8888 <oc...@gmail.com>.
Alright, PR is now open for review:
https://github.com/apache/trafficcontrol/pull/4143

On Mon, Nov 25, 2019 at 11:58 AM ocket 8888 <oc...@gmail.com> wrote:

> Yeah, I actually had to make a couple of changes to make it compliant with
> /hwinfo, but it should be good to go now.
>
> On Mon, Nov 25, 2019 at 11:29 AM Rawlin Peters <ra...@apache.org> wrote:
>
>> +1 on deprecating it. We should validate that the route is actually
>> complete before removing the `-wip` part, because that usually means a
>> rewritten route is incomplete.
>>
>> - Rawlin
>>
>> On Fri, Nov 22, 2019 at 10:09 AM ocket 8888 <oc...@gmail.com> wrote:
>> >
>> > Actually, as Jeremy pointed out on that issue, all that needs to be
>> done is
>> > rename the existing, undocumented `/hwinfo-wip` route. So I'm not really
>> > rewriting it, just adding a deprecation notice.
>> >
>> > On Fri, Nov 22, 2019 at 9:44 AM ocket 8888 <oc...@gmail.com> wrote:
>> >
>> > > The /hwinfo endpoint doesn't appear to serve any real purpose
>> (anymore?).
>> > > There's no way to insert data through the API so it can only even show
>> > > anything if the database is manually manipulated.
>> > >
>> > > This is not to be confused with /hwinfo/dtdata, which I believe we
>> already
>> > > agreed to deprecate (?).
>> > >
>> > > There's currently a deprecation notice in the documentation, but not
>> in
>> > > the API - and that deprecation was never brought up here. So is there
>> > > anyone that objects to making this deprecation official? I'm already
>> > > working on a rewrite to Go, so I can add the API deprecation warning
>> at the
>> > > same time.
>> > >
>>
>

Re: Deprecate /hwinfo

Posted by ocket 8888 <oc...@gmail.com>.
Yeah, I actually had to make a couple of changes to make it compliant with
/hwinfo, but it should be good to go now.

On Mon, Nov 25, 2019 at 11:29 AM Rawlin Peters <ra...@apache.org> wrote:

> +1 on deprecating it. We should validate that the route is actually
> complete before removing the `-wip` part, because that usually means a
> rewritten route is incomplete.
>
> - Rawlin
>
> On Fri, Nov 22, 2019 at 10:09 AM ocket 8888 <oc...@gmail.com> wrote:
> >
> > Actually, as Jeremy pointed out on that issue, all that needs to be done
> is
> > rename the existing, undocumented `/hwinfo-wip` route. So I'm not really
> > rewriting it, just adding a deprecation notice.
> >
> > On Fri, Nov 22, 2019 at 9:44 AM ocket 8888 <oc...@gmail.com> wrote:
> >
> > > The /hwinfo endpoint doesn't appear to serve any real purpose
> (anymore?).
> > > There's no way to insert data through the API so it can only even show
> > > anything if the database is manually manipulated.
> > >
> > > This is not to be confused with /hwinfo/dtdata, which I believe we
> already
> > > agreed to deprecate (?).
> > >
> > > There's currently a deprecation notice in the documentation, but not in
> > > the API - and that deprecation was never brought up here. So is there
> > > anyone that objects to making this deprecation official? I'm already
> > > working on a rewrite to Go, so I can add the API deprecation warning
> at the
> > > same time.
> > >
>

Re: Deprecate /hwinfo

Posted by Rawlin Peters <ra...@apache.org>.
+1 on deprecating it. We should validate that the route is actually
complete before removing the `-wip` part, because that usually means a
rewritten route is incomplete.

- Rawlin

On Fri, Nov 22, 2019 at 10:09 AM ocket 8888 <oc...@gmail.com> wrote:
>
> Actually, as Jeremy pointed out on that issue, all that needs to be done is
> rename the existing, undocumented `/hwinfo-wip` route. So I'm not really
> rewriting it, just adding a deprecation notice.
>
> On Fri, Nov 22, 2019 at 9:44 AM ocket 8888 <oc...@gmail.com> wrote:
>
> > The /hwinfo endpoint doesn't appear to serve any real purpose (anymore?).
> > There's no way to insert data through the API so it can only even show
> > anything if the database is manually manipulated.
> >
> > This is not to be confused with /hwinfo/dtdata, which I believe we already
> > agreed to deprecate (?).
> >
> > There's currently a deprecation notice in the documentation, but not in
> > the API - and that deprecation was never brought up here. So is there
> > anyone that objects to making this deprecation official? I'm already
> > working on a rewrite to Go, so I can add the API deprecation warning at the
> > same time.
> >

Re: Deprecate /hwinfo

Posted by ocket 8888 <oc...@gmail.com>.
Actually, as Jeremy pointed out on that issue, all that needs to be done is
rename the existing, undocumented `/hwinfo-wip` route. So I'm not really
rewriting it, just adding a deprecation notice.

On Fri, Nov 22, 2019 at 9:44 AM ocket 8888 <oc...@gmail.com> wrote:

> The /hwinfo endpoint doesn't appear to serve any real purpose (anymore?).
> There's no way to insert data through the API so it can only even show
> anything if the database is manually manipulated.
>
> This is not to be confused with /hwinfo/dtdata, which I believe we already
> agreed to deprecate (?).
>
> There's currently a deprecation notice in the documentation, but not in
> the API - and that deprecation was never brought up here. So is there
> anyone that objects to making this deprecation official? I'm already
> working on a rewrite to Go, so I can add the API deprecation warning at the
> same time.
>