Difference between revisions of "HierarchicalMultitenancy"
Vishvananda (talk | contribs) (Created page with "== Hierarchical Multitenancy == Placeholder for StrawMan around solutions.") |
Vishvananda (talk | contribs) (→Hierarchical Multitenancy) |
||
| Line 1: | Line 1: | ||
== Hierarchical Multitenancy == | == Hierarchical Multitenancy == | ||
| − | + | OpenStack needs to grow support for hierarchical ownership of objects. This enables the management subsets of users and projects in a way that is much more comfortable for private clouds. Adding this type of feature will require work across all of the projects in OpenStack. Traditionally efforts like this have stalled out because of the amount of collaboration required. For this reason, the goal is to make a small cross-functional team to design and implement this feature by producing real code. | |
| + | |||
| + | === Use Case === | ||
| + | |||
| + | Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users projects, and quotas, to list and delete resources across WidgetMaster. Martha needs to be able to set the quotas for WidgetMaster and SuperDevShop, manage users, projects, and objects across the entire system, and set quotas for the client companies as a whole. She also needs to ensure that Joe can't see or mess with anything owned by Sam. | ||
| + | |||
| + | === Problems === | ||
| + | |||
| + | * Multiple Ownership (items in projects have a single project_id owner) | ||
| + | * Quotas (quotas can only be set per project_id [+ per user in nova]) | ||
| + | * Course Policy (most policy files only consider admin vs. non-admin) | ||
| + | * Domains are not well understood | ||
| + | * Other things we haven't thought of | ||
| + | |||
| + | === Potential Solutions === | ||
| + | |||
| + | In the interest of common terminology, I'm going to refer to a "domain" as a higher level grouping of projects. Ideally this would be a nested structure, but at the very least one level is necessary. | ||
| + | |||
| + | ==== Mapping ==== | ||
| + | |||
| + | We could allow the services to request mapping information from keystone in ownership checks. For example when checking the project_id of an instance, we could make a request back to keystone to see if the project belongs to the domain. While we could do some caching here, this seems particularly bad performance for things like list. | ||
| + | |||
| + | ==== Remove Cross Project Functionality ==== | ||
| + | |||
| + | Another solution would be to remove the cross-project listing from the server side completely. This would require domain users to authenticate in the project they would like to control resources for. Listing would be handled on the client side, which would aggregate a list of all resources across the domain by listing each project individually. This is probably the cleanest approach, but it is a crummy user experience and has some very troubling performance concerns as the number of projects gets high. | ||
| + | |||
| + | ==== Multiple Ownership of Objects ==== | ||
| + | |||
| + | We could allow the project_id (or 'owner' in some openstack projects) to be a list. This would allow us to grant ownership of the resource to both the project and the domain, so list/delete operations could be done in either context. This is very flexible but has the minor disadvantage of not providing clear information of the hierarchy of things, requiring matches against multiple owners. The main disadvantage of this approach is the large set of changes it would require across projects. | ||
| + | |||
| + | ==== Hierarchical Ownership ==== | ||
| + | |||
| + | A simplified version of Multiple Ownership, instead of a list of owners, the owner is limited to a single representation of the owner. For example, the owner of an instance might be 'domainfoo.projectbar' or 'WidgetMaster.DevUnit.WebFrontend'. The structure of ownership is more static then a list, but it is much simpler in most cases. It also translates nicely into wildcard queries for ownership which means performance in the backend should be excellent. | ||
| + | |||
| + | === Straw Man === | ||
Revision as of 18:02, 28 January 2014
Contents
Hierarchical Multitenancy
OpenStack needs to grow support for hierarchical ownership of objects. This enables the management subsets of users and projects in a way that is much more comfortable for private clouds. Adding this type of feature will require work across all of the projects in OpenStack. Traditionally efforts like this have stalled out because of the amount of collaboration required. For this reason, the goal is to make a small cross-functional team to design and implement this feature by producing real code.
Use Case
Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users projects, and quotas, to list and delete resources across WidgetMaster. Martha needs to be able to set the quotas for WidgetMaster and SuperDevShop, manage users, projects, and objects across the entire system, and set quotas for the client companies as a whole. She also needs to ensure that Joe can't see or mess with anything owned by Sam.
Problems
* Multiple Ownership (items in projects have a single project_id owner) * Quotas (quotas can only be set per project_id [+ per user in nova]) * Course Policy (most policy files only consider admin vs. non-admin) * Domains are not well understood * Other things we haven't thought of
Potential Solutions
In the interest of common terminology, I'm going to refer to a "domain" as a higher level grouping of projects. Ideally this would be a nested structure, but at the very least one level is necessary.
Mapping
We could allow the services to request mapping information from keystone in ownership checks. For example when checking the project_id of an instance, we could make a request back to keystone to see if the project belongs to the domain. While we could do some caching here, this seems particularly bad performance for things like list.
Remove Cross Project Functionality
Another solution would be to remove the cross-project listing from the server side completely. This would require domain users to authenticate in the project they would like to control resources for. Listing would be handled on the client side, which would aggregate a list of all resources across the domain by listing each project individually. This is probably the cleanest approach, but it is a crummy user experience and has some very troubling performance concerns as the number of projects gets high.
Multiple Ownership of Objects
We could allow the project_id (or 'owner' in some openstack projects) to be a list. This would allow us to grant ownership of the resource to both the project and the domain, so list/delete operations could be done in either context. This is very flexible but has the minor disadvantage of not providing clear information of the hierarchy of things, requiring matches against multiple owners. The main disadvantage of this approach is the large set of changes it would require across projects.
Hierarchical Ownership
A simplified version of Multiple Ownership, instead of a list of owners, the owner is limited to a single representation of the owner. For example, the owner of an instance might be 'domainfoo.projectbar' or 'WidgetMaster.DevUnit.WebFrontend'. The structure of ownership is more static then a list, but it is much simpler in most cases. It also translates nicely into wildcard queries for ownership which means performance in the backend should be excellent.
