Fair enough. If we need metadata on the CAG, we need a CAG object.
On Thu, May 23, 2019 at 1:24 PM Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <[email protected]> wrote: > > 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] > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>> > >> >
