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

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,
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

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

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,

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

Unfortunately, we have tried that but they didn't like it very much.

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.

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

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:
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

--
Thank you,

James Bayer

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

zongwei,

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

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

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

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]

--
Thank you,

James Bayer

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

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