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] > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> >
