+1 to using query params instead of route params
On Thu, May 23, 2019 at 1:05 PM Fieck, Brennan <[email protected]>
wrote:
> I'd like to propose that instead of adding
> `/api/1.4/cacheassignmentgroups/{{id}}` that supports PUT and DELETE, we
> just let `/api/1.4/cacheassignmentgroups` handle those operations/methods
> with an identifying query parameter. There are two or three endpoints that
> do this already, I think `coordinates` is one of them.
> ________________________________________
> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> Domus (UK) Limited -OBO at Cisco) <[email protected]>
> Sent: Thursday, May 23, 2019 12:33 PM
> To: [email protected]
> Subject: Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
>
> Discussion looks to have slowed down and it was a bit of a long road, so
> I’ll summarize where we ended up.
>
> POST,GET /api/1.4/cacheassignmentgroups/
> PUT /api/1.4/cacheassignmentgroups/{id}
> {"id": 1,
> "name": "name1",
> "description": "description1",
> "cdnId": 1,
> "servers": [1,2,...n],
> "lastUpdated": "",
> }
>
> DELETE /api/1.4/cacheassignmentgroups/{id}
>
> — DS->CAG Assignments —
> PUT/POST /deliveryservices
> Add optional list of assigned CAGs to the delivery service struct
>
> — Retrieving Server<->DS Assignments —
>
> GET /api/$version/deliveryservices/:id/servers
> Will return a list of explicit server assignments unioned with servers
> assigned through CAGs. (Full server details)
>
> POST /api/$version/deliveryservices/:xmlId/servers
> Will accept a list of explicit server assignments (server names) as it
> does today.
>
>
>
> > On May 22, 2019, at 12:18 PM, Eric Friedrich -X (efriedri - TRITON UK
> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> <[email protected]> wrote:
> >
> > Sorry, should have been more clear. I was thinking about a case where
> there was no explicit assignment, only a CAG assignment.
> >
> > -Eric
> >
> >> On May 22, 2019, at 9:06 AM, Fieck, Brennan <[email protected]>
> wrote:
> >>
> >>> If someone POSTs to a DS to try and remove the name of a server that
> is assigned via a CAG, the call will return success but neither the
> explicit assignment nor the CAG assignments will be changes
> >>
> >> Why not remove the explicit assignment? IMO, a success response tells
> the client that the operation succeeded, so doing that when in fact it
> didn't is a confusing lie from the client's perspective.
> >> ________________________________________
> >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> Domus (UK) Limited -OBO at Cisco) <[email protected]>
> >> Sent: Tuesday, May 21, 2019 12:36 PM
> >> To: [email protected]
> >> Subject: Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
> >>
> >> GET /api/$version/deliveryservices/:id/servers
> >> Will return a list of explicit server assignments unioned with servers
> assigned through CAGs. (Full server details)
> >>
> >> POST /api/$version/deliveryservices/:xmlId/servers
> >> Aside: Why does this one use xmlId when all these other endpoint use
> only ID? Its rather inconsistent…
> >>
> >> Will accept a list of explicit server assignments (server names) as it
> does today.
> >> If someone POSTs to a DS with the name of a server that is assigned via
> a CAG, it will also become explicitly assigned to that DS.
> >> If someone POSTs to a DS to try and remove the name of a server that is
> assigned via a CAG, the call will return success but neither the explicit
> assignment nor the CAG assignments will be changes
> >>
> >>
> >> I was initially worried of someone doing a GET from :id/servers and
> then POSTing the response to :xmlId/servers but the formats are somehow so
> different thats not really a concern.
> >>
> >> —Eric
> >>
> >>
> >>> On May 21, 2019, at 2:05 PM, Jeremy Mitchell <[email protected]>
> wrote:
> >>>
> >>> Rawlin beat me to it.
> >>>
> >>> /api/$version/deliveryservices/:id/servers <-- tenancy is already
> checked
> >>> (i hope) on this route.
> >>>
> >>> imo if CAGs are introduced, the handler associated with that route ^^
> needs
> >>> to be modified to take CAGs into account (in addition to explicit
> server
> >>> assignments)
> >>>
> >>> On Tue, May 21, 2019 at 10:52 AM Rawlin Peters <
> [email protected]>
> >>> wrote:
> >>>
> >>>> I'm hesitant to add a server list to the delivery service object just
> >>>> because it's a lot of data (same with adding a delivery service list
> >>>> to the server object). Two of the things that are done the most in
> >>>> Traffic Ops are:
> >>>> 1. adding new servers
> >>>> 2. adding new delivery services
> >>>> Every time we do one of those things we're already increasing the size
> >>>> of the CRConfig at an M*N rate, so by adding a server list into the DS
> >>>> object and a list of DSes into the server object would gives those
> >>>> objects the same problem as the CRConfig. By adding an aggregation
> >>>> between the two of them -- the Cache Assignment Group -- it is more
> >>>> reasonable to include the list of CAGs in the server and DS objects.
> >>>>
> >>>> I agree with Eric's common questions (which DSes are assigned to a
> >>>> server and which servers are assigned to a DS), but we do already have
> >>>> specific endpoints for those two questions:
> >>>> /api/$version/servers/:id/deliveryservices
> >>>> /api/$version/deliveryservices/:id/servers
> >>>>
> >>>> Those endpoints would have to start taking into account any CAGs.
> >>>>
> >>>> - Rawlin
> >>>>
> >>>>
> >>>>
> >>>> On Tue, May 21, 2019 at 8:45 AM Fieck, Brennan
> >>>> <[email protected]> wrote:
> >>>>>
> >>>>> I'd be a fan of adding a servers array to DS objects. We don't need
> the
> >>>> whole server object in each entry, just some identifying information
> (name,
> >>>> id, type should be sufficient I would think).
> >>>>> ________________________________________
> >>>>> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> >>>> Domus (UK) Limited -OBO at Cisco) <[email protected]>
> >>>>> Sent: Tuesday, May 21, 2019 8:09 AM
> >>>>> To: [email protected]
> >>>>> Subject: Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
> >>>>>
> >>>>> I like this, but I think we still have a challenge with tenancy.
> >>>>>
> >>>>> Two of the very common questions with these groups are
> >>>>>
> >>>>> 1) Which servers are assigned to this Delivery Service (either
> >>>> individually or through a CAG).
> >>>>>
> >>>>> Using the existing proposed API, users would first need to call
> >>>> /deliveryService?id= to get a list of CAGs. Then iterate of that list
> of
> >>>> CAGs calling /server?cag= for each name/id. Not very user friendly.
> >>>>>
> >>>>> Instead, this question could be answered using
> >>>> /servers?deliveryService=<dsId>
> >>>>> But /server still needs to be tenant-aware
> >>>>>
> >>>>> I dont see a way to put it into the more tenant-friendly
> >>>> /deliveryservice endpoint without adding a “servers” field to the
> existing
> >>>> DS query params/response.
> >>>>>
> >>>>> 2) Which delivery services are assigned to this server (needed for
> >>>> remap.config generation but operators also like to see this info)
> >>>>> This could be answered with
> >>>>> /servers?id=<serverId>
> >>>>> If we are OK adding the DS assignments into the server as well
> >>>>>
> >>>>> Similarly to 1, it could also go into /deliveryservice with the
> >>>> addition of an assigned servers field in the response.
> >>>>>
> >>>>> —Eric
> >>>>>
> >>>>>> On May 19, 2019, at 7:33 PM, Chris Lemmons <[email protected]>
> wrote:
> >>>>>>
> >>>>>> I like where Rawlin is headed and I think you can take it even one
> >>>>>> step simpler. What if you moved the cacheAssignmentGroup into the
> >>>>>> server data instead? So it would look like this:
> >>>>>>
> >>>>>> Server:
> >>>>>> {
> >>>>>> "id": 1,
> >>>>>> "cags": ["foo", "quux"]
> >>>>>> ...
> >>>>>> }
> >>>>>>
> >>>>>> Delivery Service:
> >>>>>> {
> >>>>>> "xmlId": "bar",
> >>>>>> "cags": ["foo","bar"],
> >>>>>> "tenantId": 7,
> >>>>>> ...
> >>>>>> }
> >>>>>>
> >>>>>> If we need it for performance, we could map names to numbers under
> the
> >>>>>> hood, of course. This way tenancy works the way we want it to, and
> we
> >>>>>> can use capabilities to restrict who can adjust server assignments,
> >>>>>> which are, as has been observed, multi-tenant. A delivery service is
> >>>>>> assigned to a server if one of its cags matches one of the server's
> >>>>>> cags.
> >>>>>>
> >>>>>> For some bonus utility, you could allow most mutating operations to
> >>>>>> operate on cags as well, for example to set a group admin-down at
> >>>>>> once.
> >>>>>>
> >>>>>> In the future, if we need really fine control, we could potentially
> >>>>>> allow boolean logic on the cag fields, which might be useful for
> >>>>>> things like "cags": ["coreprod", "newprod & !canary"], which would
> >>>>>> match any server that had a coreprod tag, or a server with newprod
> but
> >>>>>> not canary. It could be used for managing "requirements", since not
> >>>>>> all caches might support the same set or versions of plugins
> >>>>>> (especially during a rollout of an upgrade). Imagine "cags":
> >>>>>> ["prod_east & urisigning16"] for ensuring that the DS is only
> assigned
> >>>>>> to servers with the correct version of urisigning. That sort of
> logic
> >>>>>> could let operators set up very powerful and flexible assignment
> >>>>>> systems, even in excess of what we can think up today. We'd need to
> >>>>>> design that feature carefully, though, since we probably want to be
> >>>>>> able to ask questions like "list all the DSs with the newprod cag",
> >>>>>> which can be tricky to answer if we get too clever on our fields.
> >>>>>>
> >>>>>> On Sun, May 19, 2019 at 2:20 PM Jeremy Mitchell <
> [email protected]>
> >>>> wrote:
> >>>>>>>
> >>>>>>> I think what Rawlin has proposed makes a lot of sense and would
> >>>> simplify
> >>>>>>> things w.r.t. tenancy. I like simplification. :)
> >>>>>>>
> >>>>>>> jeremy
> >>>>>>>
> >>>>>>> On Fri, May 17, 2019 at 1:59 PM Rawlin Peters <
> >>>> [email protected]>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I've been thinking about this a bit more, and I had a different
> idea
> >>>>>>>> about CAGs w.r.t. tenancy.
> >>>>>>>>
> >>>>>>>> Maybe the CAGs shouldn't contain the list of delivery services
> >>>> they're
> >>>>>>>> assigned to, and instead, the delivery service is enhanced to
> include
> >>>>>>>> the list of CAGs its assigned to. Also, instead of a CAG being
> >>>>>>>> tenantable, maybe we just keep tenancy in the delivery service so
> >>>> that
> >>>>>>>> if a tenant has access to a delivery service they are free to
> change
> >>>>>>>> their DS's CAGs at will.
> >>>>>>>>
> >>>>>>>> So we'd end up with something like:
> >>>>>>>> CAG:
> >>>>>>>> {
> >>>>>>>> "name": "foo",
> >>>>>>>> "servers": [1,2,3],
> >>>>>>>> ... (no tenant ID)
> >>>>>>>> }
> >>>>>>>> Delivery Service:
> >>>>>>>> {
> >>>>>>>> "xmlId": "bar",
> >>>>>>>> "cacheAssignmentGroups": [7, 8, 9],
> >>>>>>>> "tenantId": 7,
> >>>>>>>> ...
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> I'm thinking that "logical server groups" shouldn't really be a
> >>>>>>>> tenantable thing, because they are inherently multi-tenant, and we
> >>>>>>>> might end up creating a crazy number of overlapping CAGs for all
> >>>>>>>> tenants. Adding a new server into multiple overlapping CAGs per
> >>>> tenant
> >>>>>>>> might get out of hand. This would allow us to keep the total
> number
> >>>> of
> >>>>>>>> "logical server groups" down but still prevent a tenant from
> seeing
> >>>>>>>> another tenant's CAGs.
> >>>>>>>>
> >>>>>>>> What do you think?
> >>>>>>>>
> >>>>>>>> - Rawlin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, May 16, 2019 at 10:18 AM Jeremy Mitchell <
> >>>> [email protected]>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> yeah, maybe i overcomplicated it with my example and got it
> wrong.
> >>>>>>>>>
> >>>>>>>>> if the CAG belongs to tenant 2 and john is the only one that
> >>>> belongs to
> >>>>>>>>> tenant 2 (sally belongs to 2.1 and linda to 2.1.1), then john is
> >>>> really
> >>>>>>>> the
> >>>>>>>>> only one that can modify the CAG. and since the CAG only contains
> >>>> DS's
> >>>>>>>> from
> >>>>>>>>> tenant 2, 2.1 or 2.2, he can modify ALL the ds's in that CAG...
> >>>>>>>>>
> >>>>>>>>> so disregard what i said in my example about what sally and linda
> >>>> can
> >>>>>>>>> modify because they can't if you add tenantId to CAG.
> >>>>>>>>>
> >>>>>>>>> so i think
> >>>>>>>>>
> >>>>>>>>> 1. add a tenantID to a CAG
> >>>>>>>>> 2. enforce user tenancy on CAG post/put/delete
> >>>>>>>>> 3. on post/put, ensure the tenancy of the assigned ds's are
> >>>> compatible
> >>>>>>>> with
> >>>>>>>>> the CAG tenant
> >>>>>>>>>
> >>>>>>>>> jeremy
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, May 16, 2019 at 9:08 AM Eric Friedrich -X (efriedri -
> >>>> TRITON UK
> >>>>>>>>> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> >>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>
> >>>>>>>>>> Jeremy-
> >>>>>>>>>> Going back to your original example of the tree below.
> >>>>>>>>>>
> >>>>>>>>>> If DS baz is assigned to tenantId 2, then tenantIds 2.1, 2.1.1,
> 2.2
> >>>>>>>> cannot
> >>>>>>>>>> modify baz, right?
> >>>>>>>>>>
> >>>>>>>>>> If a CAG is created also with tenantId2, then I would expect the
> >>>> same
> >>>>>>>>>> behavior- only John as part of the 2 tenant can modify that CAG.
> >>>>>>>>>> Similarly, this CAG could only contain DS’ that belong to our
> are
> >>>>>>>> children
> >>>>>>>>>> of tenant 2.
> >>>>>>>>>>
> >>>>>>>>>> This seems to match existing behavior more closely?
> >>>>>>>>>>
> >>>>>>>>>> —Eric
> >>>>>>>>>>
> >>>>>>>>>>> On May 16, 2019, at 10:43 AM, Jeremy Mitchell <
> >>>> [email protected]
> >>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> no, capabilities are very different than tenancy.
> >>>>>>>>>>>
> >>>>>>>>>>> capabilities dictate what you "can do" - i.e. you can modify
> CAG's
> >>>>>>>> if you
> >>>>>>>>>>> have the cacheassignmentgroup-write capability
> >>>>>>>>>>> tenancy dictates what you "can do it to". in this case, if
> CAG's
> >>>>>>>> have a
> >>>>>>>>>>> tenantId and you have the cacheassignmentgroup-write
> capability,
> >>>>>>>> then you
> >>>>>>>>>>> can ONLY modify CAG's that fall in your tenancy scope.
> >>>>>>>>>>>
> >>>>>>>>>>> although different, capabilities and tenancy work hand in hand
> to
> >>>>>>>> limit
> >>>>>>>>>>> what a user can do (permissions) and what they can do that to
> >>>>>>>> (scope).
> >>>>>>>>>>>
> >>>>>>>>>>> because CAG's have an embedded tenantable resource (delivery
> >>>>>>>> services),
> >>>>>>>>>>> this makes it a bit trickier. not only should tenancy dictate
> >>>> which
> >>>>>>>> CAG's
> >>>>>>>>>>> can be modified by the user, it should also dictate how those
> >>>> CAG's
> >>>>>>>>>> should
> >>>>>>>>>>> be modified (i.e. which delivery services can be impacted by a
> >>>>>>>>>> modification)
> >>>>>>>>>>>
> >>>>>>>>>>> jeremy
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, May 15, 2019 at 3:13 PM Eric Friedrich -X (efriedri -
> >>>> TRITON
> >>>>>>>> UK
> >>>>>>>>>>> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> >>>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On May 15, 2019, at 4:16 PM, Fieck, Brennan <
> >>>>>>>> [email protected]
> >>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You could just set tenant permissions based on the owning
> tenant
> >>>>>>>> of the
> >>>>>>>>>>>> Delivery Service.
> >>>>>>>>>>>>> Should the child of a tenant be able to modify cache
> >>>> assignments of
> >>>>>>>>>> said
> >>>>>>>>>>>> tenant's Delivery Services?
> >>>>>>>>>>>>> I wouldn't think so.
> >>>>>>>>>>>> EF> Isn’t this what the capabilities are for? If a user has
> >>>>>>>>>>>> “cacheassignmentgroup-write” capability, then they can modify
> the
> >>>>>>>>>>>> assignments for any delivery services in that tenant
> >>>>>>>>>>>>
> >>>>>>>>>>>>> ________________________________________
> >>>>>>>>>>>>> From: Jeremy Mitchell <[email protected]>
> >>>>>>>>>>>>> Sent: Wednesday, May 15, 2019 1:22 PM
> >>>>>>>>>>>>> To: [email protected]
> >>>>>>>>>>>>> Subject: [EXTERNAL] Re: [PROPOSAL] Cache Assignment Group
> REST
> >>>> API
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> example tenant tree:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> root
> >>>>>>>>>>>>> - 1 (foo)
> >>>>>>>>>>>>> -- 1.1 (bar)
> >>>>>>>>>>>>> - 2 (baz)
> >>>>>>>>>>>>> -- 2.1 (bee)
> >>>>>>>>>>>>> --- 2.1.1 (bang)
> >>>>>>>>>>>>> -- 2.2 (bop)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> the foo ds belongs to tenant 1, bar ds belongs to tenant 1.1,
> >>>> etc.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> a CGA is created with tenantId=2 which means it can only have
> >>>> the
> >>>>>>>> baz,
> >>>>>>>>>>>> bee,
> >>>>>>>>>>>>> bang and bop ds's in it. John belongs to the 2 tenant and
> adds
> >>>> all
> >>>>>>>> 4
> >>>>>>>>>>>> (baz,
> >>>>>>>>>>>>> bee, bang, bop).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sally belongs to the 2.1 tenant, and only sees [bee, bang] in
> >>>> the
> >>>>>>>> CGA
> >>>>>>>>>> and
> >>>>>>>>>>>>> does an update with [], so it blows away bee (the ds in her
> >>>>>>>> tenant) and
> >>>>>>>>>>>>> bang (plus any child tenant ds's)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Linda belongs to the 2.1.1 tenant, and sees [] in the CGA
> >>>> (because
> >>>>>>>>>> sally
> >>>>>>>>>>>>> blew them all away) and does an update with [goo]. now the
> CAG
> >>>> has
> >>>>>>>> baz
> >>>>>>>>>>>> and
> >>>>>>>>>>>>> goo ds's.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> so basically, a user can only modify the ds's that they can
> see
> >>>>>>>> based
> >>>>>>>>>> on
> >>>>>>>>>>>>> their tenant (and subtenants). and a CAG can only have
> certain
> >>>>>>>> ds's in
> >>>>>>>>>> it
> >>>>>>>>>>>>> based on it's tenant...
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I "think" that would work....sounds a bit complicated but i
> >>>> really
> >>>>>>>> feel
> >>>>>>>>>>>>> like tenancy probably belongs on a CAG because of its
> >>>> relationship
> >>>>>>>> with
> >>>>>>>>>>>>> ds's. plus, then it would be nice to create CAG's for
> tenants.
> >>>> for
> >>>>>>>>>>>> example,
> >>>>>>>>>>>>> create a trial tenant and some trial ds's and some trial
> users
> >>>> and
> >>>>>>>> they
> >>>>>>>>>>>>> have no choice but to use the trial CAG that has 2 caches in
> it
> >>>> or
> >>>>>>>>>>>>> something.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> jeremy
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, May 15, 2019 at 1:01 PM Eric Friedrich -X (efriedri -
> >>>>>>>> TRITON UK
> >>>>>>>>>>>>> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> >>>>>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> What if the tenantId on the cacheassignmentgroup does not
> match
> >>>>>>>> the
> >>>>>>>>>>>>>> tenantID on one of the included delivery services?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On May 15, 2019, at 2:55 PM, Jeremy Mitchell <
> >>>>>>>> [email protected]>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I got an idea. If you made a cachegroupassignment a
> >>>> "tenantable"
> >>>>>>>>>>>>>> resource,
> >>>>>>>>>>>>>>> you could avoid the problem i mentioned above (having ds's
> >>>>>>>> hidden for
> >>>>>>>>>>>>>>> tenancy reasons). so this instead:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> {"id": 1,
> >>>>>>>>>>>>>>> "name": "name1",
> >>>>>>>>>>>>>>> "description": "description1",
> >>>>>>>>>>>>>>> tenantId: 2,
> >>>>>>>>>>>>>>> "cdnId": 1,
> >>>>>>>>>>>>>>> "servers": [1,2,...n],
> >>>>>>>>>>>>>>> "deliveryServices": [10, 20, 30, 35]
> >>>>>>>>>>>>>>> "lastUpdated": "",
> >>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> this has a nice benefit as well. i.e. certain tenants
> (content
> >>>>>>>>>>>> providers)
> >>>>>>>>>>>>>>> have access to certain cachegroupassignment configurations.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> jeremy
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, May 15, 2019 at 12:43 PM Jeremy Mitchell <
> >>>>>>>>>>>> [email protected]>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Just be careful that a GET
> >>>> /api/1.4/cacheassignmentgroups?id=4
> >>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>> return a filtered list of delivery services because of
> >>>> tenancy
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> {"id": 1,
> >>>>>>>>>>>>>>>> "name": "name1",
> >>>>>>>>>>>>>>>> "description": "description1",
> >>>>>>>>>>>>>>>> "cdnId": 1,
> >>>>>>>>>>>>>>>> "servers": [1,2,...n],
> >>>>>>>>>>>>>>>> "deliveryServices": [10, 20, 30], <-- maybe there are
> really
> >>>> 5
> >>>>>>>>>>>> delivery
> >>>>>>>>>>>>>>>> services but 2 of them (40 and 50) are hidden from you
> due to
> >>>>>>>>>> tenancy
> >>>>>>>>>>>>>>>> "lastUpdated": "",
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and a subsequent PUT with the same json (plus a new
> delivery
> >>>>>>>> service
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> is added):
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> {"id": 1,
> >>>>>>>>>>>>>>>> "name": "name1",
> >>>>>>>>>>>>>>>> "description": "description1",
> >>>>>>>>>>>>>>>> "cdnId": 1,
> >>>>>>>>>>>>>>>> "servers": [1,2,...n],
> >>>>>>>>>>>>>>>> "deliveryServices": [10, 20, 30, 35]
> >>>>>>>>>>>>>>>> "lastUpdated": "",
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> doesn't wipe out 40 and 50.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> if you do this, it begs the question. how do you remove
> ALL
> >>>> ds
> >>>>>>>>>>>>>> assignments
> >>>>>>>>>>>>>>>> from a cache assignment group?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> also, how about
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> DELETE /api/1.4/cacheassignmentgroups?id=
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> instead of
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> DELETE /api/1.4/cacheassignmentgroups/{id}
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> jeremy
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, May 15, 2019 at 12:22 PM Eric Friedrich -X
> (efriedri
> >>>> -
> >>>>>>>>>> TRITON
> >>>>>>>>>>>> UK
> >>>>>>>>>>>>>>>> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> >>>>>>>>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Feature description
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --------------------
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Mail Thread:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>
> https://lists.apache.org/thread.html/35ee49f4be1c30ff4a12c71e02897aee0e0d3d2f356640ab69ba247e@%3Cdev.trafficcontrol.apache.org%3E
> >>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>
> https://lists.apache.org/thread.html/35ee49f4be1c30ff4a12c71e02897aee0e0d3d2f356640ab69ba247e@
> >>>>>>>>>>>>>>>>> <dev.trafficcontrol.apache.org>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Github Issue:
> >>>>>>>> https://github.com/apache/trafficcontrol/issues/3557
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> API Proposal
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ------------
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> POST,GET /api/1.4/cacheassignmentgroups/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> PUT /api/1.4/cacheassignmentgroups/{id}
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> {"id": 1,
> >>>>>>>>>>>>>>>>> "name": "name1",
> >>>>>>>>>>>>>>>>> "description": "description1",
> >>>>>>>>>>>>>>>>> "cdnId": 1,
> >>>>>>>>>>>>>>>>> "servers": [1,2,...n],
> >>>>>>>>>>>>>>>>> "deliveryServices": [10, 20, 30],
> >>>>>>>>>>>>>>>>> "lastUpdated": "",
> >>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> DELETE /api/1.4/cacheassignmentgroups/{id}
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -- No request body
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This API is tenant-aware by delivery service.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Query Parameters (all optional)
> >>>>>>>>>>>>>>>>> If multiple filter parameters are specified, they are
> AND'd
> >>>>>>>>>> together
> >>>>>>>>>>>>>>>>> - id: Filter for a specific entry
> >>>>>>>>>>>>>>>>> - servers: Filter all entries containing this server
> >>>>>>>>>>>>>>>>> - deliveryService: Filter all entries containing this DS
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - limit: Return maximum number of entries (default 20)
> >>>>>>>>>>>>>>>>> - page: Return page n, with each page having limit
> number of
> >>>>>>>>>> entries
> >>>>>>>>>>>>>>>>> (default 0)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Body Parameters:
> >>>>>>>>>>>>>>>>> - id: Numeric identifier, automatically assigned on
> >>>> creation.
> >>>>>>>>>>>>>> [Read-Only,
> >>>>>>>>>>>>>>>>> not allowed in PUT/POST]
> >>>>>>>>>>>>>>>>> - name: Name of the cache assignment group
> >>>>>>>>>>>>>>>>> - description Description of the cache assignment group
> >>>>>>>>>>>>>>>>> - cdnId: ID of the CDN the cache assignment group
> belongs to
> >>>>>>>>>>>>>>>>> - servers: List of server IDs.
> >>>>>>>>>>>>>>>>> - deliveryServices: List of delivery service IDs. All
> caches
> >>>>>>>> in the
> >>>>>>>>>>>>>>>>> servers list will be assigned to these delivery services
> >>>>>>>>>>>>>>>>> - lastUpdated: Timestamp this cache assignment group was
> >>>> last
> >>>>>>>>>>>> updated.
> >>>>>>>>>>>>>>>>> [Read-Only, not allowed in PUT/POST]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>
> >
>
>
