HierarchicalMultitenancy

Meeting

We will have a meeting to discuss strawman feedback and actions on Friday, January 31st at 1600 UTC in #openstack-meeting.

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])
* Coarse Policy (most policy files only consider admin vs. non-admin)
* Data migration to the new model
* Tracking the creator vs. the owner of an object
* 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

With any of the above approaches we are going to run into various issues across the projects where the api or backend was not designed properly to handle separate administrative domains. In order to start tackling these as soon as possible, I propose that we select the last option above Hierarchical Ownership and move to implement it in a devstack branch right away. We should have an installable version with multiple domains enabled so we can start seeing the administrative issues that exist today and start solving them. This approach has the advantage of being able to be implemented without major changes to ownership inside the projects.

Devstack branch: [[1]]

Nova branch: [[2]]

Heresy

There are some long term goals which we could adopt around ownership as well. This is just a thought about how we might get to something sane. I understand this could spark some debate so just consider it an idea for now. The real thing we would want to move towards in this model is allowing a nested ownership structure on the keystone side. One level of ownership by domain really isn't sufficient here.