You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Fieck, Brennan" <Br...@comcast.com> on 2019/05/15 20:16:19 UTC
Re: [EXTERNAL] Re: [PROPOSAL] Cache Assignment Group REST API
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.
________________________________________
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 <mi...@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 <mi...@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]
> >>>
> >>>
>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by 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]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
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]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Chris Lemmons <al...@gmail.com>.
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]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>
> >
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
Sure good feedback.
> On May 23, 2019, at 3:04 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]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Jeremy Mitchell <mi...@gmail.com>.
+1 to using query params instead of route params
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 <
> rawlin.peters@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 <
> mitchell852@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]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>
> >
>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Fieck, Brennan" <Br...@comcast.com>.
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]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
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]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
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]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Fieck, Brennan" <Br...@comcast.com>.
> 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]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
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]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Jeremy Mitchell <mi...@gmail.com>.
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]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>
> >
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Rawlin Peters <ra...@gmail.com>.
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 <ra...@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 <mi...@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]
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Fieck, Brennan" <Br...@comcast.com>.
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 <ra...@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 <mi...@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]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
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 <ra...@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 <mi...@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]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Chris Lemmons <al...@gmail.com>.
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 <ra...@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 <mi...@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]
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > >
> > > >
> >
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <ra...@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 <mi...@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]
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > >
> > >
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Rawlin Peters <ra...@gmail.com>.
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 <mi...@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 <mi...@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 <mi...@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]
> > >>>>>>>
> > >>>>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <mi...@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 <mi...@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]
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
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 <mi...@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 <Br...@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 <mi...@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]
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <Br...@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 <mi...@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]
> >>>>>
> >>>>>
> >>
> >>
>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by Jeremy Mitchell <mi...@gmail.com>.
I think this is all still accurate and describes the differences between
capabilities and tenancy and also how they work together to limit access :
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910
(keep in mind capabilities are not currently implemented but hopefully will
be shorty. for now, you probably just want to assign your new endpoints to
the PrivLevelOperations role)
On Thu, May 16, 2019 at 8:43 AM Fieck, Brennan <Br...@comcast.com>
wrote:
> Sure, but the question is if those permissions permeate their parents.
> Suppose a DS exists assigned to tenant a. Tenant a has one child tenant: b.
> If a user in tenant b has 'cacheassignmentgroup-write' capability, they can
> certainly edit cache assignment groups within tenant b, but should they
> be able to edit cache assignment groups for delivery services assigned to
> tenant a? Because essentially that'll propagate to the root tenant.
> Maybe that's not a problem, but I personally think it is. So assuming that
> *is* a problem, then you're going to need to check the delivery service's
> tenancy anyway, so really having separate tenancy on this assignment
> doesn't actually do anything.
>
> IMO tenancy should only exist on objects, not relationships. To change
> relationships between things, you should check the tenancy on the
> objects being related, and then move forward if the user has the required
> capabilities. Relationships as first-class objects introduces a lot of
> complexities like what I described above.
> ________________________________________
> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
> Sent: Wednesday, May 15, 2019 3:04 PM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
>
> > On May 15, 2019, at 4:16 PM, Fieck, Brennan <Br...@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 <mi...@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]
> >>>>>
> >>>>>
> >>
> >>
>
>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Fieck, Brennan" <Br...@comcast.com>.
Sure, but the question is if those permissions permeate their parents.
Suppose a DS exists assigned to tenant a. Tenant a has one child tenant: b.
If a user in tenant b has 'cacheassignmentgroup-write' capability, they can
certainly edit cache assignment groups within tenant b, but should they
be able to edit cache assignment groups for delivery services assigned to
tenant a? Because essentially that'll propagate to the root tenant.
Maybe that's not a problem, but I personally think it is. So assuming that
*is* a problem, then you're going to need to check the delivery service's
tenancy anyway, so really having separate tenancy on this assignment
doesn't actually do anything.
IMO tenancy should only exist on objects, not relationships. To change
relationships between things, you should check the tenancy on the
objects being related, and then move forward if the user has the required
capabilities. Relationships as first-class objects introduces a lot of
complexities like what I described above.
________________________________________
From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
Sent: Wednesday, May 15, 2019 3:04 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
> On May 15, 2019, at 4:16 PM, Fieck, Brennan <Br...@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 <mi...@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 <mi...@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]
>>>>>
>>>>>
>>
>>
Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
> On May 15, 2019, at 4:16 PM, Fieck, Brennan <Br...@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 <mi...@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 <mi...@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]
>>>>>
>>>>>
>>
>>