Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API

[Chris Lemmons <al...@gmail.com>]

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)
<ef...@cisco.com.invalid> 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 <al...@gmail.com> 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
> > <Br...@comcast.com> 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) <ef...@cisco.com.INVALID>
> >> Sent: Thursday, May 23, 2019 12:33 PM
> >> To: dev@trafficcontrol.apache.org
> >> 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) <ef...@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 <Br...@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) <ef...@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 <mi...@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 <ra...@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
> >>>>>> <Br...@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) <ef...@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 <al...@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 <mi...@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.peters@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 <
> >>>>>> mitchell852@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)
> >>>>>>>>>>> <ef...@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 <
> >>>>>> mitchell852@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)
> >>>>>>>>>>>>> <ef...@cisco.com.invalid> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On May 15, 2019, at 4:16 PM, Fieck, Brennan <
> >>>>>>>>>> Brennan_Fieck@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 <mi...@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)
> >>>>>>>>>>>>>>> <ef...@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 <
> >>>>>>>>>> mitchell852@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 <
> >>>>>>>>>>>>>> mitchell852@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)
> >>>>>>>>>>>>>>>>>> <ef...@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]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>