Yes, we want to be able to link together different CAGs to form a hierarchy that can be used as an alternate to cache groups.
> On May 23, 2019, at 3:12 PM, Chris Lemmons <[email protected]> wrote: > > So, what's the benefit here of having a dedicated CAG object instead > of letting it just be a relation between caches and delivery services? > The "implied object" method of simply matching names seems > considerably more flexible going forward and it's easier to see the > relationships in the data. Is there a performance problem or extra > data we want to store on the CAG? > > 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] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>> >>> >>
