Responding to Nir's comment on https://issues.apache.org/jira/browse/TC-217 
Tenancy Feature Request

I am trying to move the debate discussions into the email system.
-Jira Ticket = Tracking development and deployment of code.
-Email List = Active Debate/Discussion
-Wiki = Summary of Key Concepts and Decisions

Tenancy - User Access to Multiple Tenants
I am struggling on the use case for viewing tenants outside one's assigned 
hierarchy.  This could get problematic in that it could allow users to see 
which companies have Tenant accounts on a CDN which could violate some 
non-disclosure agreements.  When we originally thought up Tenants, we assumed a 
user would only be assigned to one Tenant and would be able to see down their 
hierarchy.  However, we have since decided that a user may be assigned to 
multiple Tenants which should allow viewing across multiple Tenant hierarchies 
as long as they are explicitly assigned.

A Tenant is really just a container for Services and Users.  The idea of seeing 
across different ISPs was brought up.  I haven't given this enough thought yet 
but I don't envision ISPs being a blocker.  An ISP would be a container for 
Caches that reside within its network.  This would be separate structure from 
Tenancy which relates to the physical servers, networks, and pricing of 
delivery.    A User in any Tenant should be able to see the ISP market place 
available to its services and could choose how caches are assigned to its 
services.   We probably need to put some more thought into how this works.

Ryan Durfey
Sr. Product Manager - CDN | Comcast Technology Solutions
1899 Wynkoop Ste. 550 | Denver, CO 80202
M | 303-524-5099
ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com>

https://issues.apache.org/jira/browse/TC-217



[nirsopher]Nir 
Sopher<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nirsopher> 
added a comment - 5 hours ago - edited

Hi,
I believe we need to distinguish between the 2 terminologies: 
"descendent-tenants", and "allowed-tenants".
A tenants has "descendent-tenants", all the tenants beneath it in the hierarchy.
A user has its "allowed-tenants" - tenants he can view and manage.

Currently, the to terms are closely related - the "allowed-tenants" of a user 
are the "descendent-tenants" of the user's tenant.
But this is not necessarily the case.
There are a few futuristic examples for users need to be able to view tenants 
not in his own tenant hierarchy.
For example, when we have multiple ISPs in the TC, none of which can be "root" 
tenant, but the users of this tenants need to be able to view "org-tenants" in 
order to work with their delivery services.

Therefore we suggested that:
api/1.2/tenants - will show all tenants. Only tenants viewable to the current 
user will be shown.
api/1.2/tenants/:id/subtenants - will show all "tenants" decendent to the 
specified one (still, under the limitation of what the current user can view)

Do we need additionally
api/1.2/users/:id/tenants - get all the tenants viewable to the specified user 
(still, under the limitation of what the current user can view)
?

Nir

Reply via email to