Date
1 - 15 of 15
Extending Org to support multi-level Orgs (i.e. OU)
Zongwei Sun
We've been asked to support multi-level of Orgs. I realized this is huge, probably bigger than I thought. If you can give me some hints of the whole implications of this (components need to be changed, the risks and etc), it would be highly appreciated.
Thanks! Zongwei
|
|
Benjamin Black
zongwei,
could you give more detail on the problem you are hoping to solve? multi-level orgs is a solution, but i want to make sure there is clarity on the problem so we can discuss what other solutions might be possible. b On Fri, Sep 11, 2015 at 10:47 AM, Zongwei Sun <Zongwei.Sun(a)huawei.com> wrote: We've been asked to support multi-level of Orgs. I realized this is huge,
|
|
Zongwei Sun
Hi Benjamin,
For example, one of our customers today has to create two Orgs for their two braches in different geographic locations, in order to manage resources quotas and etc. separately. Also, they said that an Org hierarchy is closer to the real structure in any organization. I appreciate your help much. -Zongwei
|
|
Benjamin Black
zongwei,
if they could define multi-org quotas rather than requiring a hierarchical org structure would that meet their needs? b On Fri, Sep 11, 2015 at 11:02 AM, Zongwei Sun <Zongwei.Sun(a)huawei.com> wrote: Hi Benjamin,
|
|
Zongwei Sun
Unfortunately, we have tried that but they didn't like it very much.
|
|
Benjamin Black
what specifically did you try and what specifically didn't they like? the
more information you provide around your request the more productive the discussion will be. On Fri, Sep 11, 2015 at 11:27 AM, Zongwei Sun <Zongwei.Sun(a)huawei.com> wrote: Unfortunately, we have tried that but they didn't like it very much.
|
|
Zongwei Sun
The following is what they have asked for:
1. Total quotas for their whole ORG; 2. Each Branch has its own quotas; 3. Super users for the ORG can access each Branch. What we have offered them: 1. Created a separated ORG for each branch; 2. Each separated ORG (for a branch site) has quotas What are still missing: 1. Uniform ORG for their corporation 2. No way to set quotas for deeper organization units 3. No uniform way distribute or manage resources across their organization hierarchy. Thanks, -Zongwei
|
|
James Bayer
using separate regions or geographies implies a separate CF installations.
there is no way today to use a single quota across multiple CF installations. this "no sharing across region boundaries" approach is actually aligned with how aws manages resource limits, which are almost completely region specific [1] and do not have an uber-resource limits shared across the regions except for a few exceptions. within a single cf installation, you can set sub-quotas at a space level, which can limit the amount of resources any one space can use within an org. further down the road, there are discussions around a concept called 'isolation groups' that dieu is going to share a design doc on soon. in addition to have targeted sets of local capacity for particular tenants, isolation groups have some potential to address the use case of a remote set of cf components with capacity that is managed from a centralized cloud controller. there are many issues to work-out however as how do you handle network segments and loss of a connection to the control plane or some of the centralized information and artifacts you may need. we may end up having to federate some of that 'intended state' information as well as propagate artifacts like app source code, droplets, docker images, buildpacks, etc so that there are local copies of assets that originate from a central source. [1] http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html On Fri, Sep 11, 2015 at 11:49 AM, Zongwei Sun <Zongwei.Sun(a)huawei.com> wrote: The following is what they have asked for: -- Thank you, James Bayer
|
|
Zongwei Sun
James,
Thank you for your insights. How about using one single CF instance to build Org hierarchy which is similar to hierarchy structure of an organization - an CF Org could have multiple level of child CF Orgs? What does it to achieve this? Lots of changes to UAA, Cloud Controller? What else? Thanks, -Zongwei
|
|
Benjamin Black
zongwei,
toggle quoted messageShow quoted text
i think we are mixing problem and solution here. let's get very clear on exactly the desired user experience before jumping to what components need to change. if the data model remained the same, but an api was added to provide the desired experience on top of it then likely a lot less work would be required. from what you've said so far it doesn't look like that is what you tried with the customer. b
On Fri, Sep 11, 2015 at 2:43 PM, Zongwei Sun <Zongwei.Sun(a)huawei.com> wrote:
James,
|
|
Zongwei Sun
Benjamin,
I think we are looking for a complete solution, which mostly likely will change data model, including object model of Org, Space, Role, Resource, Permission, User and etc. -Zongwei
|
|
Zongwei Sun
One idea is that Org will refer to itself and form a TREE structure. The most descendant Org instance in the hierarchy will have a Space instance. Any parent Org won't have Space.
-Zongwei
|
|
James Bayer
zongwei, i'm unclear why a single org with multiple spaces, each
toggle quoted messageShow quoted text
potentially with their own quota, which is what the cf system does today, does not satisfy the customer's request when using a single cf installation. for example: org: foo-org quota: big-quota space: foo-east quota: small-quota space: foo-west quota: medium-quota space: foo-north quota: [none, defaults to org quota]
On Fri, Sep 11, 2015 at 3:06 PM, Zongwei Sun <Zongwei.Sun(a)huawei.com> wrote:
One idea is that Org will refer to itself and form a TREE structure. The --
Thank you, James Bayer
|
|
Deepak Vij
Hi James, let me throw more light on this and provide my perspective on all this. Essentially, what Zongwei is asking for is something that is typically available within an enterprise application platform level. To illustrate a very concrete example, application developers can make use of the general purpose platform level hierarchy mechanism and implement functionality such as resource access control and data visibility in order to enable desired application specific behavior. Let me illustrate this Role-Hierarchy based Access Control requirement typically desired in any enterprise grade application environment.
Hierarchies based Access Control One can improve the overall efficiency of an enterprise by utilizing the concept of role hierarchies. A hierarchy defines roles that have unique attributes and may be “senior” to other roles. That is, one role may be implicitly associated with permissions that are associated with another “junior” role. In essence, if used appropriately, hierarchies are a natural way of organizing roles to reflect authority, responsibility, and competency. According to an “Aggregation Hierarchy” approach, hierarchy is composed of hierarchy of roles where higher role is responsible for a superset of privileges/permissions of the lower roles. Organization chart is an example of such hierarchy (CEO->VPs->Mgrs->Employees). In such role-hierarchy based “Manager” role may be implicitly associated with permissions that are associated with another “junior” role (“Employee” role in our example). Essentially, the entire set of data visibility and access control permissions for “Manager” role is {permissions assigned to “Manager” Role} Union {permissions assigned to “Employee” Role}. To complicate this further, instead of “Aggregation Hierarchy” approach, one could also have support for “Generalization Hierarchy” approach - an inverted tree structure. In “Generalization Hierarchy”, higher role in the hierarchy is more general than the lower role. For example, root node of the hierarchy is the most general role and has the least privileges/permissions, while, leaf node has the maximum privileges/permissions. To summarize all of the above, mostly all enterprise application platforms provide support for a generic tree like hierarchical structure. I remember PeopleSoft Platform provided such generic tree structure as part of their platform. Once available, one can enable functionality such as “Role Hierarchy based Access Control & Data Visibility”, “Organization Hierarchy based Quota Allocations”, support for “Hierarchical Financial Controls” desired in the financial services industry etc. etc. Hope this all makes sense. Thanks. Regards, Deepak Vij From: James Bayer [mailto:jbayer(a)pivotal.io] Sent: Friday, September 11, 2015 8:33 PM To: Discussions about Cloud Foundry projects and the system overall. Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Extending Org to support multi-level Orgs (i.e. OU) zongwei, i'm unclear why a single org with multiple spaces, each potentially with their own quota, which is what the cf system does today, does not satisfy the customer's request when using a single cf installation. for example: org: foo-org quota: big-quota space: foo-east quota: small-quota space: foo-west quota: medium-quota space: foo-north quota: [none, defaults to org quota] On Fri, Sep 11, 2015 at 3:06 PM, Zongwei Sun <Zongwei.Sun(a)huawei.com<mailto:Zongwei.Sun(a)huawei.com>> wrote: One idea is that Org will refer to itself and form a TREE structure. The most descendant Org instance in the hierarchy will have a Space instance. Any parent Org won't have Space. -Zongwei -- Thank you, James Bayer
|
|
Deepak Vij
Hi Sree Tummidi, this is in regards to our brief discussion during Runtime PMC meeting today. As we discussed during the meeting, I would like to discuss with you more on this topic. As I don’t have your direct contact email/phone, please let me know a good time to talk. My direct email is deepak.vij(a)huawei.com<mailto:deepak.vij(a)huawei.com> (Cell: 408-806-6182). Thanks.
Regards, Deepak Vij From: Deepak Vij (A) Sent: Monday, September 14, 2015 11:17 AM To: 'cf-dev(a)lists.cloudfoundry.org' Subject: Re: Extending Org to support multi-level Orgs (i.e. OU) Hi James, let me throw more light on this and provide my perspective on all this. Essentially, what Zongwei is asking for is something that is typically available within an enterprise application platform level. To illustrate a very concrete example, application developers can make use of the general purpose platform level hierarchy mechanism and implement functionality such as resource access control and data visibility in order to enable desired application specific behavior. Let me illustrate this Role-Hierarchy based Access Control requirement typically desired in any enterprise grade application environment. Hierarchies based Access Control One can improve the overall efficiency of an enterprise by utilizing the concept of role hierarchies. A hierarchy defines roles that have unique attributes and may be “senior” to other roles. That is, one role may be implicitly associated with permissions that are associated with another “junior” role. In essence, if used appropriately, hierarchies are a natural way of organizing roles to reflect authority, responsibility, and competency. According to an “Aggregation Hierarchy” approach, hierarchy is composed of hierarchy of roles where higher role is responsible for a superset of privileges/permissions of the lower roles. Organization chart is an example of such hierarchy (CEO->VPs->Mgrs->Employees). In such role-hierarchy based “Manager” role may be implicitly associated with permissions that are associated with another “junior” role (“Employee” role in our example). Essentially, the entire set of data visibility and access control permissions for “Manager” role is {permissions assigned to “Manager” Role} Union {permissions assigned to “Employee” Role}. To complicate this further, instead of “Aggregation Hierarchy” approach, one could also have support for “Generalization Hierarchy” approach - an inverted tree structure. In “Generalization Hierarchy”, higher role in the hierarchy is more general than the lower role. For example, root node of the hierarchy is the most general role and has the least privileges/permissions, while, leaf node has the maximum privileges/permissions. To summarize all of the above, mostly all enterprise application platforms provide support for a generic tree like hierarchical structure. I remember PeopleSoft Platform provided such generic tree structure as part of their platform. Once available, one can enable functionality such as “Role Hierarchy based Access Control & Data Visibility”, “Organization Hierarchy based Quota Allocations”, support for “Hierarchical Financial Controls” desired in the financial services industry etc. etc. Hope this all makes sense. Thanks. Regards, Deepak Vij From: James Bayer [mailto:jbayer(a)pivotal.io] Sent: Friday, September 11, 2015 8:33 PM To: Discussions about Cloud Foundry projects and the system overall. Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Extending Org to support multi-level Orgs (i.e. OU) zongwei, i'm unclear why a single org with multiple spaces, each potentially with their own quota, which is what the cf system does today, does not satisfy the customer's request when using a single cf installation. for example: org: foo-org quota: big-quota space: foo-east quota: small-quota space: foo-west quota: medium-quota space: foo-north quota: [none, defaults to org quota] On Fri, Sep 11, 2015 at 3:06 PM, Zongwei Sun <Zongwei.Sun(a)huawei.com<mailto:Zongwei.Sun(a)huawei.com>> wrote: One idea is that Org will refer to itself and form a TREE structure. The most descendant Org instance in the hierarchy will have a Space instance. Any parent Org won't have Space. -Zongwei -- Thank you, James Bayer
|
|