16:04:05 <vishy> #startmeeting Hierarchical Multitenancy
16:04:06 <openstack> Meeting started Fri Mar 14 16:04:05 2014 UTC and is due to finish in 60 minutes.  The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:10 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:04:15 <VINOD__> vishy: Actually, we finished the domain quota stuff and that's why ulrich sent a mail to ask you about anything that can be done in Hierarchy multitenancy
16:04:40 <vishy> there is also a proposal for a discussion about domain support in nova
16:04:53 <vishy> VINOD__: do you have a link?
16:04:59 <vishy> #topic recent work
16:05:03 <VINOD__> vishy: you mean the domain quota stuff
16:05:08 <vishy> yeah
16:05:32 <VINOD__> https://review.openstack.org/#/c/75967/
16:05:45 <VINOD__> this one is for Nova v2 APIs for Domain Quota Management
16:06:07 <VINOD__> Nova Commands for Domain Quota ->  https://review.openstack.org/#/c/76347/
16:06:28 <vishy> #link https://review.openstack.org/#/c/75967/
16:06:36 <vishy> #link https://review.openstack.org/#/c/76347/
16:06:42 <VINOD__> #link https://review.openstack.org/#/c/78630/
16:06:51 <VINOD__> the last one is fo Nova V3 APIs
16:07:24 <vishy> ok so this would be enforcing quotas by domain instead of by nested project
16:07:31 <VINOD__> vishy: Yes
16:07:51 <vishy> I'd really like to keep the domain concept out of the projects if possible
16:08:00 <VINOD__> Unfortunately, the blueprints are not accepted for Icehouse as you uploaded it late..so we have to wait for next release
16:08:19 <VINOD__> sorry i mean i uploaded it late
16:08:40 <vishy> is there an advantage to using domains instead of nested projects in your view?
16:08:41 <raildo> vishy: IMO, it's very important to keep the concept of domain
16:08:51 <vishy> raildo: why?
16:09:26 <vishy> I think it will only last us for a little while until someone wants to add another layer between domain and project
16:09:52 <VINOD__> for me, both are same as domains can be viewed as hierarchical projects with just 3 levels
16:10:11 <schwicke> I agree with Vinod.
16:10:25 <schwicke> they are a good first step into the right direction, and most of the work is doen
16:10:28 <VINOD__> that's why we had implemented the domain quota stuff as hierarchical is still not yet decided. But we can port the code very easily
16:10:46 <vishy> VINOD__: ok
16:10:54 <vishy> still curious about raildo's opinion
16:10:55 <schwicke> this gives us time to carefully design the nested projects which should catch all use cases.
16:11:23 <vishy> schwicke: fair enough. It seems pretty straightforward although if we manage quotas for nested projects
16:11:30 <vishy> i don't think we need a new api extension
16:11:40 <vishy> we could use the existing quota management features
16:11:43 <VINOD__> vishy: That can be changed
16:11:49 <schwicke> actually, we are keen on starting to work on the extension ;-)
16:12:07 <VINOD__> vishy: I just added it because i was not sure whether i can use os-quota-sets
16:12:16 <vishy> os-quota-sets maybe not
16:12:16 <schwicke> as the blue prints are not accepted we are in fact free to change it
16:12:28 <vishy> but the regular quota management should be ok no?
16:12:29 <VINOD__> that's why i had used os-domain-quota-sets
16:12:30 <schwicke> we can easily redesign it
16:13:05 <vishy> oh sorry my bad
16:13:11 <vishy> the extension is called os-quota-sets
16:13:12 <vishy> :)
16:13:14 <vishy> I forgot
16:13:24 <VINOD__> vishy: Yes, the nova will have two quota drivers, one is called DbQuotaDriver (the current one) and the other is DomainQuotaDriver
16:13:34 <VINOD__> and both the drivers can be used in parallel.
16:13:57 <VINOD__> Like if somebody just want to use quotas at just project level, the admin can use os-quota-sets
16:14:17 <VINOD__> and if the admin wants to use quotas at domain in addition to projects, he can use os-domain-quota-sets
16:14:33 <vishy> VINOD__: if we do use nested projects, won't the existing tenant-quota comands work?
16:14:41 <VINOD__> that's why i had put them separately.
16:14:45 <vishy> meaning would the extension need to change?
16:14:59 <vishy> or is there stuff missing in os-quota-sets
16:15:15 <VINOD__> vishy: The code needs to be changed (we can keep the extension), because in the code it is assumed that they are only three levels
16:15:23 <raildo> Domin Quota in Nova,  greatly facilitates the management of a large cloud
16:15:34 <vishy> VINOD__: i mean in the os-quota-sets extension
16:15:47 <vishy> if we don't do domains, and just do nested projects
16:15:53 <vishy> is there anything missing from that extensions
16:15:55 <VINOD__> vishy: Yes, the os-quota-sets does not do domain quota..it only implements the quota at project and user level
16:16:17 <vishy> raildo: I don't see what domain quotas gives us over nested proects quota
16:16:25 <VINOD__> vishy: Yes, the code will not work as it assumes that ther is only two levels i.e projects->users
16:16:46 <vishy> VINOD__: ok but nested projects means projects->projects->projects->users
16:16:47 <VINOD__> vishy: But if we change to hierarchical like project -> project -> project -> user
16:16:54 <vishy> beat you!
16:16:54 <VINOD__> vishy: yes, exactly
16:16:55 <vishy> :)
16:17:00 <VINOD__> yeah
16:17:24 <vishy> so the keystone devs are already a bit leery about exposing domains outside of keystone
16:17:38 <VINOD__> vishy: if we forgot about domain, and want to use hierarchical one, then it requires a change in the code (keep the same extension)
16:17:40 <vishy> which is one of the reasons I like the nested project approach
16:18:07 <vishy> VINOD__: a change in the extension? or just a change in the underlying management code?
16:18:18 <VINOD__> vishy: a change in the underlying code.
16:18:45 <VINOD__> vishy: we can keep the extension same as os-quota-sets
16:18:54 <vishy> ok that is what I thought
16:19:11 <VINOD__> vishy: I mean the functions that gets called for CURD operations on os-quota-sets needs to be changed
16:19:12 <vishy> so domains vs. nested projects vs both is probably a discussion we need to have at the summit
16:19:25 <VINOD__> vishy: Yes, i guess
16:19:33 <vishy> because there are a lot of opinions :)
16:19:47 <vishy> but it is cool to have an example of how the extension would be done for domain support
16:19:51 <vishy> #topic summit sessions
16:20:01 <VINOD__> vishy: But remember if both has to be there, then we need two different extensions like os-quota-sets and os-domain-quota-sets
16:20:19 <vishy> #link http://summit.openstack.org/cfp/details/62
16:20:24 <vishy> VINOD__: right that makes sense
16:20:37 <vishy> I'm going to argue for domains being a keysotone only concept :)
16:20:41 <vishy> if it stays around
16:20:45 <VINOD__> vishy: Also, the administrator should not use these extensions at the same time
16:21:13 <vishy> so that discussion is about adding hierarchical projects in keystone
16:21:22 <raildo> vishy: tellesnobrega and I are proposing that part of nested projects at Keystone
16:21:36 <vishy> #link http://summit.openstack.org/cfp/details/58
16:21:46 <vishy> here is the one about domains in nova
16:21:49 <vishy> that is yours?
16:21:52 <raildo> yes
16:21:56 <vishy> do you have the code somewhere that I can look at?
16:21:57 <VINOD__> vishy: If nested projects are used, then why to keep domains in keystone as well
16:22:27 <vishy> VINOD__: the keystone devs have mentioned some value for integrating multiple identity management systems
16:22:41 <vishy> so essentially a domain would be a container for users for authentication purposes
16:23:23 <VINOD__> vishy: But why a user should be part of a domain. A user should just have a user name and a password. The admin can add the user to any project
16:23:27 <raildo> vishy: We're finishing up the prototype and send you to the community in the coming days
16:23:45 <VINOD__> the authentication should just include the project scope
16:24:03 <vishy> VINOD__: the domain would tell keystone which backend to talk to to validate the user/pass
16:24:16 <vishy> i.e. could be multiple ldap servers for different users
16:24:26 <vishy> it also would scope the user id
16:24:39 <vishy> so you could have gary@companya.com and gary@companyb.com
16:24:45 <vishy> i think that is the argument anyway
16:25:00 <VINOD__> vishy: To me, have domains and hierarchical together is confusing
16:25:27 <vishy> VINOD__: well I agree, but I don't really want to fight with keystone over that. If there are valid internal reasons for keeping it, fine
16:25:47 <vishy> but having nested projects and domains exposed outside of keystone is something I would prefer we didn't have :)
16:25:47 <VINOD__> vishy: Either we should keep domains or move to the hierarchical one (as domains can also be viewed as hierarchical with just 3 levels domain (can be called head project) ->project->user)
16:26:12 <vishy> some of the keystone devs are an board with that approach
16:26:16 <vishy> which i prefer as well
16:26:18 <tellesnobrega> VINOD__: in the prototype that Raildo and I implemented we have domains and hierarchical projects, they don't conflict, domain kind of contains the tree, so we can keep it compatible
16:26:35 <vishy> tellesnobrega: I think that is a good first step
16:26:50 <vishy> backwards compat is important
16:27:11 <vishy> although the blueprint talks about replacing domains with a top-level project eventually
16:27:15 <vishy> which I am all for
16:27:23 <VINOD__> tellesnobrega: Sorry, i am not proposing to drop domains..but i don't understand why both should exist together...if i am using hierarchical projects in nova, then where the domains coming into picture
16:27:40 <vishy> tellesnobrega, raildo: can you explain why you still want to have domains in nova if we have nested projects.
16:28:18 <vishy> is there some extra value that I'm missing?
16:28:29 <raildo> vishy: In relation to prototype that we implemented on nested projects in Keystone, we wonder if there is something to improve in our prototype?
16:28:52 <VINOD__> In my view, users should be registered with a username and password. Any levels of projects can be created and users can be added to a project..user can get authenticated using username, password and the project scope
16:29:04 <vishy> raildo: link?
16:29:08 <VINOD__> then any command can be run by the user can be checked using the project scope
16:29:23 <vishy> VINOD__: right that is the view
16:29:50 <raildo> vishy: https://github.com/tellesnobrega/keystone_hierarchical_projects
16:29:57 <vishy> thx
16:30:46 <vishy> hmm not easy to get a diff in that version :)
16:31:00 <tellesnobrega> vishy: in this prototype i use hierarchical ids even though adam said not to, so its compatible with your implementation
16:31:30 <vishy> ok cool
16:31:42 <vishy> I wish i could see your commits separately
16:32:00 <tellesnobrega> vishy: sorry, i had some problems during implementation, i can create a new repository with all the changes and send it to the discussion in the list
16:32:09 <vishy> tellesnobrega: that would be very helpful
16:32:15 <vishy> I'd like to take a look in more detail
16:32:22 <vishy> and I can give you feedback about potential issues
16:32:23 <tellesnobrega> will do it as soon as possible
16:32:42 <vishy> tellesnobrega: so I still would like to understand why you are proposing adding domain support for things like quotas and listing of instances
16:32:45 <vishy> if you have this?
16:33:02 <raildo> vishy: Is there any other functionality that we implement? We wanted to contribute something more to the summit.
16:33:23 <raildo> vishy: I'll send you an email trying to explain why we have domains.
16:33:57 <vishy> raildo: that would be great
16:33:59 <VINOD__> raildo: that will be very good...i am also still confused using both the features together
16:34:19 <tellesnobrega> i think domains gives a good separation of context, even though nested projects propose the same, i think that users from different places should not be allocated together in a empty slot.
16:34:28 <vishy> #action tellesnobrega clean up project code so we have clean diffs.
16:34:52 <vishy> #action raildo write an email to explain the value of domains + nested projects
16:34:55 <tellesnobrega> vishy: do you want the changes in nova, keystone and devstack or just keystone?
16:35:10 <vishy> #action vishy to review changes for hierarchical projects
16:35:15 <vishy> tellesnobrega: all of them would be great
16:35:29 <tellesnobrega> sure
16:36:05 <vishy> If we can come to a consensus about domains/projects it will make the summit easier
16:36:13 <tellesnobrega> of course
16:36:15 <vishy> assuming we all end up agreeing :)
16:36:22 <raildo> vishy: +1
16:36:25 <vishy> if not then we can at least present both sides of the argument
16:36:28 <schwicke> vinod_: we could also review our prototype.
16:37:18 <raildo> vishy: Is there any other functionality that we implement? i and tellesnobrega wanted to contribute something more to the summit
16:37:18 <schwicke> VINOD__: I mean that stuff you did a while ago on the hierarchical project quota
16:37:20 <vishy> I think it would be good to have a cross-project summit session on hierarchical multitenancy across projects
16:37:28 <vishy> hopefully presenting our idea of how it should work.
16:37:51 <raildo> ok
16:38:00 <vishy> raildo: my hope is that we can come to consensus about the "best" way to do things
16:38:03 <vishy> and present that
16:38:16 <vishy> as in here are the steps to get to good multiple ownership/ rbac / etc.
16:38:31 <VINOD__> #link https://wiki.openstack.org/wiki/POC_for_QuotaManagement
16:38:44 <VINOD__> we did this prototype long back...
16:39:07 <raildo> vishy: sounds good to me
16:39:15 <VINOD__> but i need to change this..as i had implemeneted the roles parsing from top to bottom, but somebody suggested to make it to the top
16:39:15 <vishy> in my mind it is 1. hierarchical projects in keystone 2. data migration of owners to nested.projects  3. prefix matching for policy and functions 4. Multiple ownership
16:39:23 <vishy> but there is still some debate
16:39:44 <vishy> VINOD__: yeah that was me
16:39:51 <VINOD__> vishy: sorry
16:39:53 <vishy> there are also a bunch of sub points in there
16:40:59 <VINOD__> vishy: should i need to change the POC to what you suggested and post the diff of code to all?
16:47:17 <schwicke> vishy: do you want to action item that ?
16:49:37 <schwicke> have to leave, sorry.
16:49:51 <vishy> #action VINOD__ to change the poc and post diff
16:49:58 <VINOD__> ok
16:49:59 <vishy> sorry had to step away for a minute
16:50:00 <schwicke> ok
16:50:26 <vishy> so lets do our actions and meet next week to discuss our position about domains and projects
16:50:27 <vishy> and steps
16:50:32 <vishy> sound good?
16:50:43 <VINOD__> ok..its sound good
16:50:51 <schwicke> sounds good
16:50:54 <schwicke> see you next week!
16:50:57 <raildo> ok
16:50:58 <vishy> #info discussion next week will be around domains vs. nested projects vs. both
16:51:23 <tellesnobrega> see you guys
16:51:29 <vishy> #info goal is to come to consensus around best path forward and a specific set of steps to bring nested or domain support to other projects
16:51:32 <vishy> #endmeeting