Re: Go Code Coverage Merge lib
+0 I don't know if small libraries _require_ approval, but getting community input doesn't hurt. We just want to be careful about using large libraries that could stop being maintained, and difficult to replace. Or that could introduce security vulnerabilities. And that licenses are compatible, of course. `gocovmerge` is licensed BSD 2-Clause, which is fine (@lavu1241 here's the list, if you don't have it already: https://apache.org/legal/resolved.html#category-a). It looks like it isn't really popular or well-maintained, but it's also tiny and trivial to rewrite if we have to. If it were me, I'd probably just write it myself, but I'm a +0 on adding it. On Thu, Aug 15, 2019 at 2:05 PM Lavanya Bathina wrote: > Hi, > I am using the below lib to merge the code coverage report from multiple > runs. > "github.com/wadey/gocovmerge" > > Based on the review, it seems there is specific way in which external > libraries can be used or it needs approval. I am pretty new to the open > source world. Seeking help to understand the process or procedure to use > the above library. > > > -- > Thanks and Regards, > Lavanya Bathina > 303-676-7825 >
Re: Deprecate /capabilities/{{name}}
Again, I disagree with you, yet we are on the same side here. I care about the community just the same as you do, albeit with somewhat different values in mind. I don't want to purposely break users by making unnecessary breaking changes to the API, but I also don't want to build and support an API that is full of unnecessary footguns. If a user ends up being broken by the removal of these seemingly useless capabilities endpoints, then I would question why they were even using them in the first place because they are not currently used anywhere in the codebase currently and have no effect whatsoever. IMO we are more likely to lose users due to having a more dangerous and unintuitive API than we are by removing endpoints that serve no purpose. - Rawlin On Thu, Aug 15, 2019 at 1:58 PM Robert Butts wrote: > > >We should be able to make exceptions to "the rules" in exceptional cases. > Deleting useless routes that provide no purpose to the system is what I > would consider an exceptional case. > > As above, I would consider an exception case where it's an unreasonably > huge amount of code and work, or danger. I do not consider it "exceptional" > for small, easy routes. > > > We should support API promises where they make sense and not get too > carried away with the "rules" where it doesn't make sense. > > -1. It does make sense here, it makes sense to maintain a stable project, > to attract users and committers. It's not about "following the rules," it's > about not breaking users. > > > Let's not let this thread devolve into API versioning. > > I agree, it should be a separate thread, if you want to raise this issue > again. But you can't state strong opinions that have huge impact (IMO > negatively) on the project, and then tell other people not to comment. That > isn't really fair to an open community. > > > On Thu, Aug 15, 2019 at 1:51 PM Robert Butts wrote: > > > @mitchell852 How is that? > > https://cwiki.apache.org/confluence/display/TC/API+Guidelines#APIGuidelines-Deprecation > > > > > by that I mean not rewriting them to Go and changing the Perl routes to > > add a deprecation alert. Although, API promises and what-not aside, I think > > we could probably just delete the Perl routes right now because I can't > > imagine a valid reason to even be using those endpoints currently. > > > > >I don't necessarily agree with rewriting deprecated Perl routes in Go. I > > think if a route is deprecated in release N, we can remove it in release > > N+1 (next major version). > > > > -1 > > > > >But if we're going to discuss this immediately, here's my two cents: > > We've committed to API versioning. That means that you can't remove an > > endpoint that existed in version 1.x without moving to 2.x. So not > > rewriting all of the Perl endpoints under `/api/1.x/` would mean that we're > > committed to Perl sticking around until API 2.x. I think that's a bad idea, > > because the codebase gets much easier to work with when there's only set of > > source for a particular component. > > > > > You can't deprecate an endpoint in ATC version N and remove it in N+1, > > because the ATC version does not govern the TO API > > > > +1 > > > > The API version the the TC version are _completely separate things_. Even > > if the TC major version is increased, the API has its own "version promise" > > to avoid breaking clients. > > > > The problem here is not just breaking a TC CDN operator, it's also > > breaking their clients. TC has an API, the whole point of an API is to be > > able to program against it reliably. > > > > The whole point of an "API Promise" is to allow clients, even if their CDN > > operator upgrades TO, to write scripts, which continue to work. Which don't > > break every few months, every time we delete some random route, because we > > decided we didn't think anyone was using it. > > > > Taking a vote and saying "does anyone here use this route? No? Motion > > passes, delete!" completely violates that promise. Most clients, many > > operators even, are not on our development or user lists. > > > > We already don't have as many users and contributors of TC as we'd like. > > This kind of thing, deleting random routes from an alleged API, is only > > going to lose more TC users and contributors, and make people who consider > > it, stop. Nobody wants to use a product that constantly breaks. > > > > I could understand, if it was this huge massive burden to support these > > routes. But it isn't. Versioning isn't hard, we just did it badly in Go > > (it's a little better now). And the routes we want to "deprecate" are > > mostly small and really not very much work to write and maintain. > > > > If someone has an old, unused route that's massive, and a huge amount of > > logic and work to maintain, I could understand asking to stop supporting > > it. In which case, IMO the "least evil" is to still serve the route, and > > return a 500 code. I might could even +1 it. Unhappily. Because it is > > breaking
Go Code Coverage Merge lib
Hi, I am using the below lib to merge the code coverage report from multiple runs. "github.com/wadey/gocovmerge" Based on the review, it seems there is specific way in which external libraries can be used or it needs approval. I am pretty new to the open source world. Seeking help to understand the process or procedure to use the above library. -- Thanks and Regards, Lavanya Bathina 303-676-7825
Re: Deprecate /capabilities/{{name}}
>We should be able to make exceptions to "the rules" in exceptional cases. Deleting useless routes that provide no purpose to the system is what I would consider an exceptional case. As above, I would consider an exception case where it's an unreasonably huge amount of code and work, or danger. I do not consider it "exceptional" for small, easy routes. > We should support API promises where they make sense and not get too carried away with the "rules" where it doesn't make sense. -1. It does make sense here, it makes sense to maintain a stable project, to attract users and committers. It's not about "following the rules," it's about not breaking users. > Let's not let this thread devolve into API versioning. I agree, it should be a separate thread, if you want to raise this issue again. But you can't state strong opinions that have huge impact (IMO negatively) on the project, and then tell other people not to comment. That isn't really fair to an open community. On Thu, Aug 15, 2019 at 1:51 PM Robert Butts wrote: > @mitchell852 How is that? > https://cwiki.apache.org/confluence/display/TC/API+Guidelines#APIGuidelines-Deprecation > > > by that I mean not rewriting them to Go and changing the Perl routes to > add a deprecation alert. Although, API promises and what-not aside, I think > we could probably just delete the Perl routes right now because I can't > imagine a valid reason to even be using those endpoints currently. > > >I don't necessarily agree with rewriting deprecated Perl routes in Go. I > think if a route is deprecated in release N, we can remove it in release > N+1 (next major version). > > -1 > > >But if we're going to discuss this immediately, here's my two cents: > We've committed to API versioning. That means that you can't remove an > endpoint that existed in version 1.x without moving to 2.x. So not > rewriting all of the Perl endpoints under `/api/1.x/` would mean that we're > committed to Perl sticking around until API 2.x. I think that's a bad idea, > because the codebase gets much easier to work with when there's only set of > source for a particular component. > > > You can't deprecate an endpoint in ATC version N and remove it in N+1, > because the ATC version does not govern the TO API > > +1 > > The API version the the TC version are _completely separate things_. Even > if the TC major version is increased, the API has its own "version promise" > to avoid breaking clients. > > The problem here is not just breaking a TC CDN operator, it's also > breaking their clients. TC has an API, the whole point of an API is to be > able to program against it reliably. > > The whole point of an "API Promise" is to allow clients, even if their CDN > operator upgrades TO, to write scripts, which continue to work. Which don't > break every few months, every time we delete some random route, because we > decided we didn't think anyone was using it. > > Taking a vote and saying "does anyone here use this route? No? Motion > passes, delete!" completely violates that promise. Most clients, many > operators even, are not on our development or user lists. > > We already don't have as many users and contributors of TC as we'd like. > This kind of thing, deleting random routes from an alleged API, is only > going to lose more TC users and contributors, and make people who consider > it, stop. Nobody wants to use a product that constantly breaks. > > I could understand, if it was this huge massive burden to support these > routes. But it isn't. Versioning isn't hard, we just did it badly in Go > (it's a little better now). And the routes we want to "deprecate" are > mostly small and really not very much work to write and maintain. > > If someone has an old, unused route that's massive, and a huge amount of > logic and work to maintain, I could understand asking to stop supporting > it. In which case, IMO the "least evil" is to still serve the route, and > return a 500 code. I might could even +1 it. Unhappily. Because it is > breaking the API promise, and will break users, and is one more straw on > the camel's back of making a poor, unstable project that people don't want > to use or contribute to. In fact, I've considered proposing just that for > the ATS config endpoints (not because they're work to maintain, but because > they're a lot of duplicate logic that's likely to go untested and be > dangerously error-prone). > > But for endpoints that are a very small amount of work to port and > maintain, it's a big loss to the stability of the project for a very small > development gain. Even if one organization doesn't feel it, it will make us > lose (and not get in the first place) users and contributors, which add > huge value to the project, and we should be trying our best to get, not > drive away. > > @ocket sorry to derail your thread. > > >I could get behind deprecating the ability to mutate capabilities through > the API > > I will say, the version promise applies to the endpoint itsel
Re: Deprecate /capabilities/{{name}}
Well all I mean by "deprecate" is saying as much in the docs, and possibly
returning a warning-level alert. The endpoints would still exist, work as
advertised, and (IMO ought to be) translated to Go.
On Thu, Aug 15, 2019 at 1:51 PM Robert Butts wrote:
> @mitchell852 How is that?
>
> https://cwiki.apache.org/confluence/display/TC/API+Guidelines#APIGuidelines-Deprecation
>
> > by that I mean not rewriting them to Go and changing the Perl routes to
> add a deprecation alert. Although, API promises and what-not aside, I think
> we could probably just delete the Perl routes right now because I can't
> imagine a valid reason to even be using those endpoints currently.
>
> >I don't necessarily agree with rewriting deprecated Perl routes in Go. I
> think if a route is deprecated in release N, we can remove it in release
> N+1 (next major version).
>
> -1
>
> >But if we're going to discuss this immediately, here's my two cents: We've
> committed to API versioning. That means that you can't remove an endpoint
> that existed in version 1.x without moving to 2.x. So not rewriting all of
> the Perl endpoints under `/api/1.x/` would mean that we're committed to
> Perl sticking around until API 2.x. I think that's a bad idea, because the
> codebase gets much easier to work with when there's only set of source for
> a particular component.
>
> > You can't deprecate an endpoint in ATC version N and remove it in N+1,
> because the ATC version does not govern the TO API
>
> +1
>
> The API version the the TC version are _completely separate things_. Even
> if the TC major version is increased, the API has its own "version promise"
> to avoid breaking clients.
>
> The problem here is not just breaking a TC CDN operator, it's also breaking
> their clients. TC has an API, the whole point of an API is to be able to
> program against it reliably.
>
> The whole point of an "API Promise" is to allow clients, even if their CDN
> operator upgrades TO, to write scripts, which continue to work. Which don't
> break every few months, every time we delete some random route, because we
> decided we didn't think anyone was using it.
>
> Taking a vote and saying "does anyone here use this route? No? Motion
> passes, delete!" completely violates that promise. Most clients, many
> operators even, are not on our development or user lists.
>
> We already don't have as many users and contributors of TC as we'd like.
> This kind of thing, deleting random routes from an alleged API, is only
> going to lose more TC users and contributors, and make people who consider
> it, stop. Nobody wants to use a product that constantly breaks.
>
> I could understand, if it was this huge massive burden to support these
> routes. But it isn't. Versioning isn't hard, we just did it badly in Go
> (it's a little better now). And the routes we want to "deprecate" are
> mostly small and really not very much work to write and maintain.
>
> If someone has an old, unused route that's massive, and a huge amount of
> logic and work to maintain, I could understand asking to stop supporting
> it. In which case, IMO the "least evil" is to still serve the route, and
> return a 500 code. I might could even +1 it. Unhappily. Because it is
> breaking the API promise, and will break users, and is one more straw on
> the camel's back of making a poor, unstable project that people don't want
> to use or contribute to. In fact, I've considered proposing just that for
> the ATS config endpoints (not because they're work to maintain, but because
> they're a lot of duplicate logic that's likely to go untested and be
> dangerously error-prone).
>
> But for endpoints that are a very small amount of work to port and
> maintain, it's a big loss to the stability of the project for a very small
> development gain. Even if one organization doesn't feel it, it will make us
> lose (and not get in the first place) users and contributors, which add
> huge value to the project, and we should be trying our best to get, not
> drive away.
>
> @ocket sorry to derail your thread.
>
> >I could get behind deprecating the ability to mutate capabilities through
> the API
>
> I will say, the version promise applies to the endpoint itself, not the
> server. If we want to make the TO Server stop supporting mutating
> Capabilities, we can make the API endpoints that do so return 400 codes.
> IMO we should be very careful and thoughtful when we do things like that,
> because it does break clients, even if we're still technically versioning
> correctly. But there are cases where it's worth the cost, to create a
> better system. But I'm not close enough to the Capabilities feature to have
> an opinion.
>
>
>
>
>
> On Thu, Aug 15, 2019 at 1:16 PM Rawlin Peters
> wrote:
>
> > On Thu, Aug 15, 2019 at 1:01 PM Robert Butts wrote:
> > >
> > > >- don't bother converting `/capabilities/{{name}}` from Perl to Go
> > >
> > > But we still have to support those routes, until API 1.x is no longer
> > > supported, whic
Re: Deprecate /capabilities/{{name}}
@mitchell852 How is that?
https://cwiki.apache.org/confluence/display/TC/API+Guidelines#APIGuidelines-Deprecation
> by that I mean not rewriting them to Go and changing the Perl routes to
add a deprecation alert. Although, API promises and what-not aside, I think
we could probably just delete the Perl routes right now because I can't
imagine a valid reason to even be using those endpoints currently.
>I don't necessarily agree with rewriting deprecated Perl routes in Go. I
think if a route is deprecated in release N, we can remove it in release
N+1 (next major version).
-1
>But if we're going to discuss this immediately, here's my two cents: We've
committed to API versioning. That means that you can't remove an endpoint
that existed in version 1.x without moving to 2.x. So not rewriting all of
the Perl endpoints under `/api/1.x/` would mean that we're committed to
Perl sticking around until API 2.x. I think that's a bad idea, because the
codebase gets much easier to work with when there's only set of source for
a particular component.
> You can't deprecate an endpoint in ATC version N and remove it in N+1,
because the ATC version does not govern the TO API
+1
The API version the the TC version are _completely separate things_. Even
if the TC major version is increased, the API has its own "version promise"
to avoid breaking clients.
The problem here is not just breaking a TC CDN operator, it's also breaking
their clients. TC has an API, the whole point of an API is to be able to
program against it reliably.
The whole point of an "API Promise" is to allow clients, even if their CDN
operator upgrades TO, to write scripts, which continue to work. Which don't
break every few months, every time we delete some random route, because we
decided we didn't think anyone was using it.
Taking a vote and saying "does anyone here use this route? No? Motion
passes, delete!" completely violates that promise. Most clients, many
operators even, are not on our development or user lists.
We already don't have as many users and contributors of TC as we'd like.
This kind of thing, deleting random routes from an alleged API, is only
going to lose more TC users and contributors, and make people who consider
it, stop. Nobody wants to use a product that constantly breaks.
I could understand, if it was this huge massive burden to support these
routes. But it isn't. Versioning isn't hard, we just did it badly in Go
(it's a little better now). And the routes we want to "deprecate" are
mostly small and really not very much work to write and maintain.
If someone has an old, unused route that's massive, and a huge amount of
logic and work to maintain, I could understand asking to stop supporting
it. In which case, IMO the "least evil" is to still serve the route, and
return a 500 code. I might could even +1 it. Unhappily. Because it is
breaking the API promise, and will break users, and is one more straw on
the camel's back of making a poor, unstable project that people don't want
to use or contribute to. In fact, I've considered proposing just that for
the ATS config endpoints (not because they're work to maintain, but because
they're a lot of duplicate logic that's likely to go untested and be
dangerously error-prone).
But for endpoints that are a very small amount of work to port and
maintain, it's a big loss to the stability of the project for a very small
development gain. Even if one organization doesn't feel it, it will make us
lose (and not get in the first place) users and contributors, which add
huge value to the project, and we should be trying our best to get, not
drive away.
@ocket sorry to derail your thread.
>I could get behind deprecating the ability to mutate capabilities through
the API
I will say, the version promise applies to the endpoint itself, not the
server. If we want to make the TO Server stop supporting mutating
Capabilities, we can make the API endpoints that do so return 400 codes.
IMO we should be very careful and thoughtful when we do things like that,
because it does break clients, even if we're still technically versioning
correctly. But there are cases where it's worth the cost, to create a
better system. But I'm not close enough to the Capabilities feature to have
an opinion.
On Thu, Aug 15, 2019 at 1:16 PM Rawlin Peters
wrote:
> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts wrote:
> >
> > >- don't bother converting `/capabilities/{{name}}` from Perl to Go
> >
> > But we still have to support those routes, until API 1.x is no longer
> > supported, which is far in the future.
> >
> > We should still rewrite deprecated Perl routes in Go, just so we can get
> > rid of Perl sooner than that.
>
> I don't necessarily agree with rewriting deprecated Perl routes in Go.
> I think if a route is deprecated in release N, we can remove it in
> release N+1 (next major version). We shouldn't be stuck maintaining
> useless endpoints for eternity (especially these ones which don't even
> make
Re: Deprecate /capabilities/{{name}}
On Thu, Aug 15, 2019 at 1:36 PM ocket wrote:
>
> Well, we've immediately derailed, lol. I just want to know if I can mark
> `/capabilities/{{name}}` as deprecated.
>
> But if we're going to discuss this immediately, here's my two cents: We've
> committed to API versioning. That means that you can't remove an endpoint
> that existed in version 1.x without moving to 2.x. So not rewriting all of
> the Perl endpoints under `/api/1.x/` would mean that we're committed to
> Perl sticking around until API 2.x. I think that's a bad idea, because the
> codebase gets much easier to work with when there's only set of source for
> a particular component.
>
> You can't deprecate an endpoint in ATC version N and remove it in N+1,
> because the ATC version does not govern the TO API (except insofar as I
> believe introducing 2.x would necessitate bumping the ATC version).
>
> Of course, we could always just _not_ version the API explicitly, which is
> A-OK by me. But we've had that discussion before, and this particular email
> thread isn't the place to re-hash it.
Let's not let this thread devolve into API versioning. We should be
able to make exceptions to "the rules" in exceptional cases. Deleting
useless routes that provide no purpose to the system is what I would
consider an exceptional case. We should support API promises where
they make sense and not get too carried away with the "rules" where it
doesn't make sense. At the end of the day we need to remove footguns
and evolve the API. Those are things that should benefit the project
as a whole, and I see no benefit in aimlessly following "the rules"
where it doesn't make sense to.
- Rawlin
Re: Deprecate /capabilities/{{name}}
I think we're in a bit of a unique situation with capabilities because
they're not being used currently to enforce permissions. And I agree,
allowing create/update/delete of capabilities and api_capabilities (aka
endpoints) was probably a poor design decision and was really only added to
allow operators to dynamically add endpoints/capabilities to support any
custom endpoints added via TO extensions.
Just to clarify:
capability: endpoint
ds-read: GET /api/deliveryservices
ds-read: GET /api/deliveryservices/:id
ds-write: POST /api/deliveryservices
ds-write: PUT /api/deliveryservices/:id
ds-write: DELETE /api/deliveryservices/:id
you really should not be able to dynamically add additional endpoints into
the ds-write capability. Butsay you really want a PATCH endpoint for
delivery services and the OS community doesn't want it. You could add the
Patch route in TO extensions and then you could CREATE the `PATCH
/api/deliveryservices/:id` endpoint via the API and assign it to the
ds-write capability. But since creating a endpoint is not really a run-time
activity, I agree with Rawlin that we should have something like
my-custom-seeds.sql that adds custom things to your DB at startup.
so i'm in favor of complete deletion of create/update/delete of
capabilities and api_endpoints.
and yes, i'm good with marking `/capabilities/{{name}}` as deprecated
Jeremy
On Thu, Aug 15, 2019 at 1:38 PM ocket wrote:
> That said, I could get behind deprecating the ability to mutate
> capabilities through the API, as long as there's a simple way for
> extensions to declare their capabilities. Ideally that wouldn't mean an
> extension needs to manually access the database.
>
> On Thu, Aug 15, 2019 at 1:35 PM ocket wrote:
>
> > Well, we've immediately derailed, lol. I just want to know if I can mark
> > `/capabilities/{{name}}` as deprecated.
> >
> > But if we're going to discuss this immediately, here's my two cents:
> We've
> > committed to API versioning. That means that you can't remove an endpoint
> > that existed in version 1.x without moving to 2.x. So not rewriting all
> of
> > the Perl endpoints under `/api/1.x/` would mean that we're committed to
> > Perl sticking around until API 2.x. I think that's a bad idea, because
> the
> > codebase gets much easier to work with when there's only set of source
> for
> > a particular component.
> >
> > You can't deprecate an endpoint in ATC version N and remove it in N+1,
> > because the ATC version does not govern the TO API (except insofar as I
> > believe introducing 2.x would necessitate bumping the ATC version).
> >
> > Of course, we could always just _not_ version the API explicitly, which
> is
> > A-OK by me. But we've had that discussion before, and this particular
> email
> > thread isn't the place to re-hash it.
> >
> > On Thu, Aug 15, 2019 at 1:16 PM Rawlin Peters
> > wrote:
> >
> >> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts wrote:
> >> >
> >> > >- don't bother converting `/capabilities/{{name}}` from Perl to Go
> >> >
> >> > But we still have to support those routes, until API 1.x is no longer
> >> > supported, which is far in the future.
> >> >
> >> > We should still rewrite deprecated Perl routes in Go, just so we can
> get
> >> > rid of Perl sooner than that.
> >>
> >> I don't necessarily agree with rewriting deprecated Perl routes in Go.
> >> I think if a route is deprecated in release N, we can remove it in
> >> release N+1 (next major version). We shouldn't be stuck maintaining
> >> useless endpoints for eternity (especially these ones which don't even
> >> make sense to support). If removing these deprecated endpoints before
> >> API 2.x is going to break any users out there, I would be glad to hear
> >> out their valid use cases for having us support them.
> >>
> >> Another example is the `cdns/:name/configs/routing` endpoint. It was a
> >> half-implemented attempt at breaking up the CRConfig and was not
> >> returning any valid or useful data at all when I last looked into it.
> >> Just because it exists in the Perl does not mean we should have to
> >> take it with us to Go. And the `cachegroup_fallbacks` endpoints, which
> >> are now supported in cachegroups proper. And the `/riak/stats`
> >> endpoint, which was mainly for triage purposes during the integration
> >> of Riak for Traffic Vault. We don't really have a good reason to keep
> >> those endpoints around IMO.
> >>
> >> - Rawlin
> >>
> >
>
Re: Deprecate /capabilities/{{name}}
That said, I could get behind deprecating the ability to mutate
capabilities through the API, as long as there's a simple way for
extensions to declare their capabilities. Ideally that wouldn't mean an
extension needs to manually access the database.
On Thu, Aug 15, 2019 at 1:35 PM ocket wrote:
> Well, we've immediately derailed, lol. I just want to know if I can mark
> `/capabilities/{{name}}` as deprecated.
>
> But if we're going to discuss this immediately, here's my two cents: We've
> committed to API versioning. That means that you can't remove an endpoint
> that existed in version 1.x without moving to 2.x. So not rewriting all of
> the Perl endpoints under `/api/1.x/` would mean that we're committed to
> Perl sticking around until API 2.x. I think that's a bad idea, because the
> codebase gets much easier to work with when there's only set of source for
> a particular component.
>
> You can't deprecate an endpoint in ATC version N and remove it in N+1,
> because the ATC version does not govern the TO API (except insofar as I
> believe introducing 2.x would necessitate bumping the ATC version).
>
> Of course, we could always just _not_ version the API explicitly, which is
> A-OK by me. But we've had that discussion before, and this particular email
> thread isn't the place to re-hash it.
>
> On Thu, Aug 15, 2019 at 1:16 PM Rawlin Peters
> wrote:
>
>> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts wrote:
>> >
>> > >- don't bother converting `/capabilities/{{name}}` from Perl to Go
>> >
>> > But we still have to support those routes, until API 1.x is no longer
>> > supported, which is far in the future.
>> >
>> > We should still rewrite deprecated Perl routes in Go, just so we can get
>> > rid of Perl sooner than that.
>>
>> I don't necessarily agree with rewriting deprecated Perl routes in Go.
>> I think if a route is deprecated in release N, we can remove it in
>> release N+1 (next major version). We shouldn't be stuck maintaining
>> useless endpoints for eternity (especially these ones which don't even
>> make sense to support). If removing these deprecated endpoints before
>> API 2.x is going to break any users out there, I would be glad to hear
>> out their valid use cases for having us support them.
>>
>> Another example is the `cdns/:name/configs/routing` endpoint. It was a
>> half-implemented attempt at breaking up the CRConfig and was not
>> returning any valid or useful data at all when I last looked into it.
>> Just because it exists in the Perl does not mean we should have to
>> take it with us to Go. And the `cachegroup_fallbacks` endpoints, which
>> are now supported in cachegroups proper. And the `/riak/stats`
>> endpoint, which was mainly for triage purposes during the integration
>> of Riak for Traffic Vault. We don't really have a good reason to keep
>> those endpoints around IMO.
>>
>> - Rawlin
>>
>
Re: Deprecate /capabilities/{{name}}
Well, we've immediately derailed, lol. I just want to know if I can mark
`/capabilities/{{name}}` as deprecated.
But if we're going to discuss this immediately, here's my two cents: We've
committed to API versioning. That means that you can't remove an endpoint
that existed in version 1.x without moving to 2.x. So not rewriting all of
the Perl endpoints under `/api/1.x/` would mean that we're committed to
Perl sticking around until API 2.x. I think that's a bad idea, because the
codebase gets much easier to work with when there's only set of source for
a particular component.
You can't deprecate an endpoint in ATC version N and remove it in N+1,
because the ATC version does not govern the TO API (except insofar as I
believe introducing 2.x would necessitate bumping the ATC version).
Of course, we could always just _not_ version the API explicitly, which is
A-OK by me. But we've had that discussion before, and this particular email
thread isn't the place to re-hash it.
On Thu, Aug 15, 2019 at 1:16 PM Rawlin Peters
wrote:
> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts wrote:
> >
> > >- don't bother converting `/capabilities/{{name}}` from Perl to Go
> >
> > But we still have to support those routes, until API 1.x is no longer
> > supported, which is far in the future.
> >
> > We should still rewrite deprecated Perl routes in Go, just so we can get
> > rid of Perl sooner than that.
>
> I don't necessarily agree with rewriting deprecated Perl routes in Go.
> I think if a route is deprecated in release N, we can remove it in
> release N+1 (next major version). We shouldn't be stuck maintaining
> useless endpoints for eternity (especially these ones which don't even
> make sense to support). If removing these deprecated endpoints before
> API 2.x is going to break any users out there, I would be glad to hear
> out their valid use cases for having us support them.
>
> Another example is the `cdns/:name/configs/routing` endpoint. It was a
> half-implemented attempt at breaking up the CRConfig and was not
> returning any valid or useful data at all when I last looked into it.
> Just because it exists in the Perl does not mean we should have to
> take it with us to Go. And the `cachegroup_fallbacks` endpoints, which
> are now supported in cachegroups proper. And the `/riak/stats`
> endpoint, which was mainly for triage purposes during the integration
> of Riak for Traffic Vault. We don't really have a good reason to keep
> those endpoints around IMO.
>
> - Rawlin
>
Re: Deprecate /capabilities/{{name}}
On Thu, Aug 15, 2019 at 1:01 PM Robert Butts wrote:
>
> >- don't bother converting `/capabilities/{{name}}` from Perl to Go
>
> But we still have to support those routes, until API 1.x is no longer
> supported, which is far in the future.
>
> We should still rewrite deprecated Perl routes in Go, just so we can get
> rid of Perl sooner than that.
I don't necessarily agree with rewriting deprecated Perl routes in Go.
I think if a route is deprecated in release N, we can remove it in
release N+1 (next major version). We shouldn't be stuck maintaining
useless endpoints for eternity (especially these ones which don't even
make sense to support). If removing these deprecated endpoints before
API 2.x is going to break any users out there, I would be glad to hear
out their valid use cases for having us support them.
Another example is the `cdns/:name/configs/routing` endpoint. It was a
half-implemented attempt at breaking up the CRConfig and was not
returning any valid or useful data at all when I last looked into it.
Just because it exists in the Perl does not mean we should have to
take it with us to Go. And the `cachegroup_fallbacks` endpoints, which
are now supported in cachegroups proper. And the `/riak/stats`
endpoint, which was mainly for triage purposes during the integration
of Riak for Traffic Vault. We don't really have a good reason to keep
those endpoints around IMO.
- Rawlin
Re: Deprecate /capabilities/{{name}}
TO-Perl currently has full CRUD API support for both /capabilities and
/api_capabilities. It seems to me like capabilities are
statically-defined in terms of what the actual capabilities of the
system are at the current version (via seeds.sql), so we don't really
need API-level support for Creating/Updating/Deleting capabilities.
That just seems like a footgun that we can easily eliminate from the
system altogether. I _do_ still think we should be able to READ the
existing capabilities via the API (for knowing what capabilities can
be added to a role), but that's about it.
If a TO extension adds a new route and wishes to use
roles/capabilities, it should insert its own capabilities into TODB at
startup/load time.
So, I would vote that we deprecate all Create/Update/Delete endpoints
for /capabilities and /api_capabilities, and by that I mean not
rewriting them to Go and changing the Perl routes to add a deprecation
alert. Although, API promises and what-not aside, I think we could
probably just delete the Perl routes right now because I can't imagine
a valid reason to even be using those endpoints currently.
- Rawlin
On Thu, Aug 15, 2019 at 12:15 PM ocket wrote:
>
> I recently marked a PR that rewrites the `/capabilities` endpoint in Go as
> ready for review (https://github.com/apache/trafficcontrol/pull/3870) and
> with it added handlers for PUT and DELETE. That means that
> `/capabilities/{{name}}` will no longer do anything that `/capabilities`
> does not, so is it alright if we deprecate it?
>
> There's also been some discussion about deprecating the ability to
> create/modify/delete capabilities at all (mostly on that PR itself, atm).
> I'd like to answer my above question before we get into that, though.
Re: Deprecate /capabilities/{{name}}
Maybe so I don't have to keep asking the question of what "deprecate" means
to us, we should add it to
https://cwiki.apache.org/confluence/display/TC/API+Guidelines so it's very
clear how we handle deprecated routes.
On Thu, Aug 15, 2019 at 12:54 PM Jeremy Mitchell
wrote:
> Can you elaborate on what "deprecate" actually means? Here's what i think
> it means:
>
> - don't bother converting `/capabilities/{{name}}` from Perl to Go and
> adding some kind of deprecation message to the `/capabilities/{{name}}`
> Perl response.
>
> On Thu, Aug 15, 2019 at 12:15 PM ocket wrote:
>
>> I recently marked a PR that rewrites the `/capabilities` endpoint in Go as
>> ready for review (https://github.com/apache/trafficcontrol/pull/3870) and
>> with it added handlers for PUT and DELETE. That means that
>> `/capabilities/{{name}}` will no longer do anything that `/capabilities`
>> does not, so is it alright if we deprecate it?
>>
>> There's also been some discussion about deprecating the ability to
>> create/modify/delete capabilities at all (mostly on that PR itself, atm).
>> I'd like to answer my above question before we get into that, though.
>>
>
Re: Deprecate /capabilities/{{name}}
>- don't bother converting `/capabilities/{{name}}` from Perl to Go
But we still have to support those routes, until API 1.x is no longer
supported, which is far in the future.
We should still rewrite deprecated Perl routes in Go, just so we can get
rid of Perl sooner than that.
On Thu, Aug 15, 2019 at 12:54 PM Jeremy Mitchell
wrote:
> Can you elaborate on what "deprecate" actually means? Here's what i think
> it means:
>
> - don't bother converting `/capabilities/{{name}}` from Perl to Go and
> adding some kind of deprecation message to the `/capabilities/{{name}}`
> Perl response.
>
> On Thu, Aug 15, 2019 at 12:15 PM ocket wrote:
>
> > I recently marked a PR that rewrites the `/capabilities` endpoint in Go
> as
> > ready for review (https://github.com/apache/trafficcontrol/pull/3870)
> and
> > with it added handlers for PUT and DELETE. That means that
> > `/capabilities/{{name}}` will no longer do anything that `/capabilities`
> > does not, so is it alright if we deprecate it?
> >
> > There's also been some discussion about deprecating the ability to
> > create/modify/delete capabilities at all (mostly on that PR itself, atm).
> > I'd like to answer my above question before we get into that, though.
> >
>
Re: Deprecate /capabilities/{{name}}
Can you elaborate on what "deprecate" actually means? Here's what i think
it means:
- don't bother converting `/capabilities/{{name}}` from Perl to Go and
adding some kind of deprecation message to the `/capabilities/{{name}}`
Perl response.
On Thu, Aug 15, 2019 at 12:15 PM ocket wrote:
> I recently marked a PR that rewrites the `/capabilities` endpoint in Go as
> ready for review (https://github.com/apache/trafficcontrol/pull/3870) and
> with it added handlers for PUT and DELETE. That means that
> `/capabilities/{{name}}` will no longer do anything that `/capabilities`
> does not, so is it alright if we deprecate it?
>
> There's also been some discussion about deprecating the ability to
> create/modify/delete capabilities at all (mostly on that PR itself, atm).
> I'd like to answer my above question before we get into that, though.
>
Deprecate /capabilities/{{name}}
I recently marked a PR that rewrites the `/capabilities` endpoint in Go as
ready for review (https://github.com/apache/trafficcontrol/pull/3870) and
with it added handlers for PUT and DELETE. That means that
`/capabilities/{{name}}` will no longer do anything that `/capabilities`
does not, so is it alright if we deprecate it?
There's also been some discussion about deprecating the ability to
create/modify/delete capabilities at all (mostly on that PR itself, atm).
I'd like to answer my above question before we get into that, though.
