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