16:02:11 <vishy> #startmeeting Hierarchical Multitenancy
16:02:11 <openstack> Meeting started Fri Mar 21 16:02:11 2014 UTC and is due to finish in 60 minutes.  The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:14 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:03:04 <VINOD_> i too
16:03:06 <raildo> i am
16:03:09 <vishy> hi guys
16:03:16 <VINOD_> hi
16:03:21 <raildo> hi
16:04:20 <vishy> i ges tellesnobrega is not here?
16:04:48 <vishy> * guess
16:05:04 <vishy> #topic actions from last week
16:05:07 <raildo> vishy: no, he had to travel today, could not attend the meeting
16:05:14 <vishy> so tellesnobrega put up his code
16:05:22 <vishy> I reviewed it and it looks pretty ideal to me
16:05:43 <vishy> i made one comment about dot separating the hierarchical ids
16:05:56 <vishy> but other than that it seems pretty simple and effective
16:06:02 <vishy> did anyone else look at it?
16:07:43 <vishy> i also checked out VINOD's changes for quota management
16:07:46 <tiamar> vishy: I did, I also share your opinion, I think we have time to improve it but I have doubts on to where it should go
16:07:51 <vishy> and it also seems pretty simple
16:08:01 <VINOD_> vishy: ok
16:08:17 <vishy> the advantage of this is the set of changes is actually pretty small
16:08:43 <vishy> between my code telles code and VINOD I think we have a workable solution that is less than a few hundred lines of code
16:09:25 <VINOD_> vishy: for quota management, i think not much changes are required..the only thing i guess is in quota tables, the project id should store the entire hierarchy like projA.projA1.projA2 instead of projA2
16:09:38 <vishy> right
16:09:54 <vishy> I do have some code for storing a cache of project names from ids
16:10:00 <vishy> and looking stuff up in keystone
16:10:00 <VINOD_> ok
16:10:05 <vishy> but it is based on grizzly code
16:10:15 <vishy> so i need to update it
16:11:12 <VINOD_> vishy: But i guess one thing is still undecided is whether we should go with ids or names for project
16:11:32 <VINOD_> i mean like projA.projA1 or <id of projA>.<id of projA1>
16:11:45 <vishy> VINOD_: based on the discussion on the ML I think we have to keep storing ids
16:12:04 <vishy> VINOD_: we can however pass both names and ids in separate fields
16:12:29 <VINOD_> vishy: I think its better to pass both..
16:12:31 <vishy> which would make the id/name cache avoid calls back to keystone in many cases
16:12:47 <vishy> I'm worried about storing both
16:12:56 <vishy> because that means db migrations to add extra fields
16:12:57 <vishy> etc.
16:12:58 <VINOD_> vishy: yes, exactly and also avoids the problem if in case some where we need ids and some where we need names
16:13:16 <vishy> so i think the idea would be we store ids
16:13:23 <vishy> but keep an in memory map to names
16:13:32 <vishy> which we can update from the data passed
16:13:58 <tiamar> are project names immutable?
16:14:02 <vishy> no
16:14:06 <VINOD_> But why we need database migrations...keystone basing on the authentication scope can construct the names as well as ids by looking into its database and put them into the token
16:14:22 <vishy> VINOD_: i mean in the other projects
16:14:29 <vishy> i.e. in nova instances table
16:14:33 <vishy> we just store ids
16:14:37 <VINOD_> oh!!!ok
16:14:38 <vishy> not both
16:14:42 <VINOD_> i got it
16:14:51 <VINOD_> i was slightly confused
16:15:05 <VINOD_> vishy: that's seems ok for me
16:15:23 <vishy> ok so I'm going to modify the wiki to explain the plan in more detail
16:15:33 <vishy> with links to sample code
16:15:38 <VINOD_> great
16:15:47 <vishy> #topic next steps
16:15:56 <vishy> #action vishy to update wiki with current plan
16:16:31 <vishy> so the next thing is to figure out meetings for the summit
16:16:42 <vishy> #topic summit sessions
16:17:06 <vishy> i think we need one session on adding hierachical projects to keystone
16:17:36 <raildo> http://summit.openstack.org/cfp/details/62
16:17:52 <schwicke> who of us is going there ?
16:18:00 <vishy> which would include calcuating the inherited roles and passing two new fields to the clients: hierarchical_ids and hierarchical_Names
16:18:34 <vishy> there is a session proposed already for this
16:19:50 <vishy> there is also a session proposed to nova around domains and quotas
16:20:10 <vishy> http://summit.openstack.org/cfp/details/58
16:20:22 <VINOD_> if i am right tiago will represent for nova about domains and quotas..right?
16:20:26 <vishy> personally i would suggest we do a combined session where we discuss domains an projects
16:20:44 <tiamar> I'm actualling not going to the summit - But Raildo and Telles will
16:21:02 <VINOD_> tiamar: ok
16:21:04 <vishy> i believe there was supposed to be a post about why we should keep domains and hierarchical projects?
16:21:31 <vishy> i don't recall seeing that
16:21:46 <raildo> vishy: I agree to discuss two subjects in the same session
16:21:49 <vishy> i think raildo was going to put that together?
16:22:24 <raildo> vishy: I'd send an email but I thought I discuss here
16:22:42 <vishy> finally I think we need one session in common proposing the plan for all projects
16:23:04 <vishy> #action vishy to propose a cross-project session about hierarchical multitenancy
16:23:23 <vishy> #topic why keep domains if we have hierarchical projects
16:24:02 <vishy> raildo: lets discuss then
16:25:06 <raildo> vishy: I gathered some ideas about why keeping domains with hierarchical projects such as: In our case domains might be mapped to our big customers, and serve to group the tenants they own. In this case, the domain information would help determine whom to account for the used resources.
16:26:48 <vishy> raildo: I don't see what advantage calling the big customer thing a "domain" vs just a "project"
16:26:57 <schwicke> raildo: Couldn't have phrased it any better
16:27:04 <schwicke> it's the same for us.
16:27:57 <raildo> vishy: IMO This being 2 different concepts in OpenStack makes it easier to implement sophisticated algorithms of isolation and access control and delegation while maintaining backward compatibility.
16:29:31 <raildo> vishy: Federation needs domains to be used as containers of users, ie, we need domains to obtain multi-tenancy with keystone federated.
16:29:37 <vishy> raildo: I think the major issue is that both keystone and other projects are not in support of passing around the domain id
16:29:54 <vishy> raildo: ok that one makes sense
16:30:06 <vishy> raildo: that's what I've been thinking of domains as
16:30:10 <vishy> containers of users
16:30:17 <vishy> which would be a keystone only concept
16:30:22 <raildo> vishy: sure
16:30:30 <vishy> i.e. the other projects don't need to know about domains at all
16:30:36 <vishy> which i think is way simpler
16:31:48 <gabriel-bezerra> vishy: regarding other projects, it could store the domain id as the first domain in the hierarchy of the project id. I think they don't need a new database column just to store the domain id.
16:32:00 <raildo> vishy: I do not think the concept of domains is complex, I believe it is even simpler than hierarchical projects.
16:32:01 <gabriel-bezerra> * they could
16:34:23 <vishy> gabriel-bezerra: they could but i don't like tying projects to domains if they are containers for users
16:34:50 <vishy> gabriel-bezerra: that woudl stop cross-comptany projects for example
16:34:56 <tiamar> vishy: in keystone domains are also containers for projects
16:35:13 <gabriel-bezerra> but aren't them also containers of projects? Can a project be shared among domains?
16:35:16 <vishy> and i don't think it is any harder to just create a top level project matching the domain
16:35:24 <vishy> gabriel-bezerra: my point is that they shouldn't
16:35:28 <tiamar> vishy: there are a BP for chross-domain integration based on trusts
16:35:42 <vishy> gabriel-bezerra: but this is theoretical
16:35:55 <vishy> I'm ok with them being the top-level and passed along
16:35:56 <raildo> vishy: https://blueprints.launchpad.net/keystone/+spec/domain-trusts
16:36:22 <vishy> honestly i think that is way more complicated but if that's how the keystone devs want to do it thats ok with me
16:36:58 <vishy> having to walk up the hierarchy to get roles and then at the end of the chain check the domain
16:37:00 <vishy> seems weird
16:37:19 <vishy> although dolph proposed implementing domains as a top-level project
16:37:23 <vishy> with just a different flag
16:37:28 <vishy> which seems fine to me
16:37:45 <raildo> great
16:38:17 <raildo> vishy: I believe we can gain much more by keeping the two concepts together
16:41:36 <vishy> ok I will update the wiki with options on domains
16:41:54 <vishy> I have to head out
16:41:59 <vishy> is there anything else to discuss
16:42:09 <vishy> #topic open discussion
16:42:25 <vishy> #action vishy to include domain options in wiki update
16:43:20 <VINOD_> vishy: nothing more from our side
16:43:21 <tiamar> vishy: we could see on the roles in Telles code, what you think?
16:44:17 <vishy> sure
16:45:10 <tiamar> vishy: ok, we will do this
16:48:08 <vishy> #action tiamar to try to deal with role inheritance in telles code
16:48:15 <vishy> ok thanks guys
16:48:19 <vishy> #endmeeting