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. But....say 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 8888 <ocket8...@gmail.com> 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 8888 <ocket8...@gmail.com> 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 <rawlin.pet...@gmail.com>
> > wrote:
> >
> >> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts <r...@apache.org> 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
> >>
> >
>

Reply via email to