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) > <efrie...@cisco.com.INVALID> 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 <brennan_fi...@comcast.com> >> 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) <efrie...@cisco.com.INVALID> >> Sent: Tuesday, May 21, 2019 12:36 PM >> To: dev@trafficcontrol.apache.org >> 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 <mitchell...@gmail.com> 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 <rawlin.pet...@gmail.com> >>> 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 >>>> <brennan_fi...@comcast.com> 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) <efrie...@cisco.com.INVALID> >>>>> Sent: Tuesday, May 21, 2019 8:09 AM >>>>> To: dev@trafficcontrol.apache.org >>>>> 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 <alfic...@gmail.com> 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 <mitchell...@gmail.com> >>>> 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 < >>>> rawlin.pet...@gmail.com> >>>>>>> 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 < >>>> mitchell...@gmail.com> >>>>>>>> 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) >>>>>>>>> <efrie...@cisco.com.invalid> 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 < >>>> mitchell...@gmail.com >>>>>>>>> >>>>>>>>>> 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) >>>>>>>>>>> <efrie...@cisco.com.invalid> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On May 15, 2019, at 4:16 PM, Fieck, Brennan < >>>>>>>> brennan_fi...@comcast.com >>>>>>>>>>> >>>>>>>>>>>> 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 <mitchell...@gmail.com> >>>>>>>>>>>>> Sent: Wednesday, May 15, 2019 1:22 PM >>>>>>>>>>>>> To: dev@trafficcontrol.apache.org >>>>>>>>>>>>> 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) >>>>>>>>>>>>> <efrie...@cisco.com.invalid> 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 < >>>>>>>> mitchell...@gmail.com> >>>>>>>>>>>>>> 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 < >>>>>>>>>>>> mitchell...@gmail.com> >>>>>>>>>>>>>>> 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) >>>>>>>>>>>>>>>> <efrie...@cisco.com.invalid> 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] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >>>> >> >