example tenant tree: root - 1 (foo) -- 1.1 (bar) - 2 (baz) -- 2.1 (bee) --- 2.1.1 (bang) -- 2.2 (bop)
the foo ds belongs to tenant 1, bar ds belongs to tenant 1.1, etc. a CGA is created with tenantId=2 which means it can only have the baz, bee, bang and bop ds's in it. John belongs to the 2 tenant and adds all 4 (baz, bee, bang, bop). Sally belongs to the 2.1 tenant, and only sees [bee, bang] in the CGA and does an update with [], so it blows away bee (the ds in her tenant) and bang (plus any child tenant ds's) Linda belongs to the 2.1.1 tenant, and sees [] in the CGA (because sally blew them all away) and does an update with [goo]. now the CAG has baz and goo ds's. so basically, a user can only modify the ds's that they can see based on their tenant (and subtenants). and a CAG can only have certain ds's in it based on it's tenant... I "think" that would work....sounds a bit complicated but i really feel like tenancy probably belongs on a CAG because of its relationship with ds's. plus, then it would be nice to create CAG's for tenants. for example, create a trial tenant and some trial ds's and some trial users and they have no choice but to use the trial CAG that has 2 caches in it or something. jeremy On Wed, May 15, 2019 at 1:01 PM Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <[email protected]> wrote: > What if the tenantId on the cacheassignmentgroup does not match the > tenantID on one of the included delivery services? > > On May 15, 2019, at 2:55 PM, Jeremy Mitchell <[email protected]> > wrote: > > > > I got an idea. If you made a cachegroupassignment a "tenantable" > resource, > > you could avoid the problem i mentioned above (having ds's hidden for > > tenancy reasons). so this instead: > > > > {"id": 1, > > "name": "name1", > > "description": "description1", > > tenantId: 2, > > "cdnId": 1, > > "servers": [1,2,...n], > > "deliveryServices": [10, 20, 30, 35] > > "lastUpdated": "", > > } > > > > this has a nice benefit as well. i.e. certain tenants (content providers) > > have access to certain cachegroupassignment configurations. > > > > jeremy > > > > > > > > > > On Wed, May 15, 2019 at 12:43 PM Jeremy Mitchell <[email protected]> > > wrote: > > > >> Just be careful that a GET /api/1.4/cacheassignmentgroups?id=4 doesn't > >> return a filtered list of delivery services because of tenancy > >> > >> {"id": 1, > >> "name": "name1", > >> "description": "description1", > >> "cdnId": 1, > >> "servers": [1,2,...n], > >> "deliveryServices": [10, 20, 30], <-- maybe there are really 5 delivery > >> services but 2 of them (40 and 50) are hidden from you due to tenancy > >> "lastUpdated": "", > >> } > >> > >> and a subsequent PUT with the same json (plus a new delivery service > that > >> is added): > >> > >> {"id": 1, > >> "name": "name1", > >> "description": "description1", > >> "cdnId": 1, > >> "servers": [1,2,...n], > >> "deliveryServices": [10, 20, 30, 35] > >> "lastUpdated": "", > >> } > >> > >> doesn't wipe out 40 and 50. > >> > >> if you do this, it begs the question. how do you remove ALL ds > assignments > >> from a cache assignment group? > >> > >> also, how about > >> > >> DELETE /api/1.4/cacheassignmentgroups?id= > >> > >> instead of > >> > >> DELETE /api/1.4/cacheassignmentgroups/{id} > >> > >> jeremy > >> > >> On Wed, May 15, 2019 at 12:22 PM Eric Friedrich -X (efriedri - TRITON UK > >> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > >> <[email protected]> wrote: > >> > >>> Feature description > >>> > >>> -------------------- > >>> > >>> Mail Thread: > >>> > https://lists.apache.org/thread.html/35ee49f4be1c30ff4a12c71e02897aee0e0d3d2f356640ab69ba247e@%3Cdev.trafficcontrol.apache.org%3E > >>> < > >>> > https://lists.apache.org/thread.html/35ee49f4be1c30ff4a12c71e02897aee0e0d3d2f356640ab69ba247e@ > >>> <dev.trafficcontrol.apache.org>> > >>> > >>> Github Issue: https://github.com/apache/trafficcontrol/issues/3557 > >>> > >>> > >>> API Proposal > >>> > >>> ------------ > >>> > >>> POST,GET /api/1.4/cacheassignmentgroups/ > >>> > >>> PUT /api/1.4/cacheassignmentgroups/{id} > >>> > >>> {"id": 1, > >>> "name": "name1", > >>> "description": "description1", > >>> "cdnId": 1, > >>> "servers": [1,2,...n], > >>> "deliveryServices": [10, 20, 30], > >>> "lastUpdated": "", > >>> } > >>> > >>> > >>> DELETE /api/1.4/cacheassignmentgroups/{id} > >>> > >>> -- No request body > >>> > >>> This API is tenant-aware by delivery service. > >>> > >>> Query Parameters (all optional) > >>> If multiple filter parameters are specified, they are AND'd together > >>> - id: Filter for a specific entry > >>> - servers: Filter all entries containing this server > >>> - deliveryService: Filter all entries containing this DS > >>> > >>> - limit: Return maximum number of entries (default 20) > >>> - page: Return page n, with each page having limit number of entries > >>> (default 0) > >>> > >>> Body Parameters: > >>> - id: Numeric identifier, automatically assigned on creation. > [Read-Only, > >>> not allowed in PUT/POST] > >>> - name: Name of the cache assignment group > >>> - description Description of the cache assignment group > >>> - cdnId: ID of the CDN the cache assignment group belongs to > >>> - servers: List of server IDs. > >>> - deliveryServices: List of delivery service IDs. All caches in the > >>> servers list will be assigned to these delivery services > >>> - lastUpdated: Timestamp this cache assignment group was last updated. > >>> [Read-Only, not allowed in PUT/POST] > >>> > >>> > >
