On Feb 4, 2014, at 11:54 AM, Tiwari, Arvind <[email protected]> wrote:
> Hi Vish, > > I am sorry as I am proposing just a solution approach below but no code so > far. > > ### Problem and Requirement ### > As per the problem description it seems to me that "Martha, the owner of > ProductionIT" is not a cloud provider (correct me if wrong) and she uses > someone else cloud infrastructure (like public cloud) to provide services to > multiple Enterprise clients. In this case I was considering Martha to be the “owner” of the cloud, but it could go one level deeper for sure. > > After reading further it seems to me that we want different administrative > boundaries and isolation among them, so that "Joe can manage/mess-up resource > for WidgetMaster and Sam for SuperDevShop but not each other" at the same > time "Martha should be allowed to manage resources from both". > > ### Requirements based on my understanding ### > 1. Joe can manage/mess-up resource for WidgetMaster and Sam for SuperDevShop > but not each other. > 2. Martha should be able to manage resources from both. Correct, that sums up the use case. > > ### Solution ### (*This solution is backed-up by production working > implementation*) > > In a nutshell, We need ability to setup hierarchicical administrative > boundaries within a cloud deployment, so that multiple service providers > (like Martha) can be created and have administrative privilege across > multiple domains which falls under their administrative boundary. > > Note: There will be only one level of hierarchy as multi level hierarchy is > complex to implement and does not perform well. Give that, > "Martha/ProductionIT" will be at root of hierarchy, Joe and Sam will stand at > leaf of the hierarchy. I disagree that multiple levels needs to be complex or have bad performance. Especially considering it will rarely if ever go beyond 3 levels. > > (Solution for Req#1) Keystone has concept of domains which is nothing but a > notion of an administrative boundary where admin of one domain is allowed to > manage resources within a specific domain but not across domains, provided > correct policy is in place. This is already in place so there will be no > change needed to support Req #1. No change in keystone, but this information still needs to be passed to the projects and interpreted properly. > > (Solution for Req#2) > We can extend the notion of domains further to define a root (parent/super) > domain and leaf (child/sub) domains, one set of root and leaf domains will > define a hierarchicical administrative boundary. Glue between root and leafs > will be different roles, that way "Matha" can become "NovaAdmin" (or any > other role) in WidgetMaster or SuperDevShop. Yes this is one approach if keystone really wants to extend domains to work this way, but I think this is more complex than just using nested projects. Having domains contain domains containing projects is less intuitive than projects all the way down. Vish > > > ### Pros ### > Complete IAM based solution. > More logically fits in hierarchicical model. > Absolutely no (or minimal) changes to services (Nova, Swift ....) > > ### Cons ### > Most of the changes is needed in Keystone and its data model (Domain, Roles). > Some change required in OSLO policy engine for policy evaluation. > Service (Nova, Swift ....) may have define new roles. > > > Let me know if I am not making sense here or have any questions. > > > Arvind > > -----Original Message----- > From: Vishvananda Ishaya [mailto:[email protected]] > Sent: Monday, February 03, 2014 2:58 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy > Discussion > > Hello Again! > > At the meeting last week we discussed some options around getting true > multitenancy in nova. The use case that we are trying to support can be > described as follows: > > "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, as well as the > ability to list and delete resources across WidgetMaster. Martha needs to be > able to set the quotas for both 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." > > As per the plan I outlined in the meeting I have implemented a > Proof-of-Concept that would allow me to see what changes were required in > nova to get scoped tenancy working. I used a simple approach of faking out > heirarchy by prepending the id of the larger scope to the id of the smaller > scope. Keystone uses uuids internally, but for ease of explanation I will > pretend like it is using the name. I think we can all agree that > 'orga.projecta' is more readable than > 'b04f9ea01a9944ac903526885a2666dec45674c5c2c6463dad3c0cb9d7b8a6d8'. > > The code basically creates the following five projects: > > orga > orga.projecta > orga.projectb > orgb > orgb.projecta > > I then modified nova to replace everywhere where it searches or limits policy > by project_id to do a prefix match. This means that someone using project > 'orga' should be able to list/delete instances in orga, orga.projecta, and > orga.projectb. > > You can find the code here: > > > https://github.com/vishvananda/devstack/commit/10f727ce39ef4275b613201ae1ec7655bd79dd5f > > https://github.com/vishvananda/nova/commit/ae4de19560b0a3718efaffb6c205c7a3c372412f > > Keeping in mind that this is a prototype, but I'm hoping to come to some kind > of consensus as to whether this is a reasonable approach. I've compiled a > list of pros and cons. > > Pros: > > * Very easy to understand > * Minimal changes to nova > * Good performance in db (prefix matching uses indexes) > * Could be extended to cover more complex scenarios like multiple owners or > multiple scopes > > Cons: > > * Nova has no map of the hierarchy > * Moving projects would require updates to ownership inside of nova > * Complex scenarios involving delegation of roles may be a bad fit > * Database upgrade to hierarchy could be tricky > > If this seems like a reasonable set of tradeoffs, there are a few things that > need to be done inside of nova bring this to a complete solution: > > * Prefix matching needs to go into oslo.policy > * Should the tenant_id returned by the api reflect the full 'orga.projecta', > or just the child 'projecta' or match the scope: i.e. the first if you are > authenticated to orga and the second if you are authenticated to the project? > * Possible migrations for existing project_id fields > * Use a different field for passing ownership scope instead of overloading > project_id > * Figure out how nested quotas should work > * Look for other bugs relating to scoping > > Also, we need to decide how keystone should construct and pass this > information to the services. The obvious case that could be supported today > would be to allow a single level of hierarchy using domains. For example, if > domains are active, keystone could pass domain.project_id for > ownership_scope. This could be controversial because potentially domains are > just for grouping users and shouldn't be applied to projects. > > I think the real value of this approach would be to allow nested projects > with role inheritance. When keystone is creating the token, it could walk the > tree of parent projects, construct the set of roles, and construct the > ownership_scope as it walks to the root of the tree. > > Finally, similar fixes will need to be made in the other projects to bring > this to a complete solution. > > Please feel free to respond with any input, and we will be having another > Hierarchical Multitenancy Meeting on Friday at 1600 UTC to discuss. > > Vish > > On Jan 28, 2014, at 10:35 AM, Vishvananda Ishaya <[email protected]> > wrote: > >> Hi Everyone, >> >> I apologize for the obtuse title, but there isn't a better succinct term to >> describe what is needed. OpenStack has no support for multiple owners of >> objects. This means that a variety of private cloud use cases are simply not >> supported. Specifically, objects in the system can only be managed on the >> tenant level or globally. >> >> The key use case here is to delegate administration rights for a group of >> tenants to a specific user/role. There is something in Keystone called a >> "domain" which supports part of this functionality, but without support from >> all of the projects, this concept is pretty useless. >> >> In IRC today I had a brief discussion about how we could address this. I >> have put some details and a straw man up here: >> >> https://wiki.openstack.org/wiki/HierarchicalMultitenancy >> >> I would like to discuss this strawman and organize a group of people to get >> actual work done by having an irc meeting this Friday at 1600UTC. I know >> this time is probably a bit tough for Europe, so if we decide we need a >> regular meeting to discuss progress then we can vote on a better time for >> this meeting. >> >> https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting >> >> Please note that this is going to be an active team that produces code. We >> will *NOT* spend a lot of time debating approaches, and instead focus on >> making something that works and learning as we go. The output of this team >> will be a MultiTenant devstack install that actually works, so that we can >> ensure the features we are adding to each project work together. >> >> Vish > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
