16:12:16 <schwicke> #startmeeting HierarchicalMultitenancy
16:12:17 <openstack> Meeting started Fri Jun 20 16:12:16 2014 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:12:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:12:21 <openstack> The meeting name has been set to 'hierarchicalmultitenancy'
16:17:15 <raildo> hi
16:17:31 <Sajeesh> hi raildo
16:17:38 <raildo> hi Sajeesh
16:19:21 <raildo> As I promised I created the keystone-spec https://review.openstack.org/#/c/101017/
16:19:33 <raildo> #link https://review.openstack.org/#/c/101017/
16:19:34 <schwicke> great
16:19:38 <Sajeesh> good
16:19:52 <schwicke> I have some networking issues it seems. Just dropped out for a moment
16:20:07 <raildo> There are some things to be corrected, I intend to do that today.
16:20:29 <schwicke> #action Sajeesh review https://review.openstack.org/#/c/101017/
16:20:45 <Sajeesh> ok ,I will check it
16:21:37 <Sajeesh> raildo,I have completed the design part and have started implementation
16:21:47 <raildo> Sajeesh: great
16:22:17 <schwicke> we've been discussing a few things which need some clarification
16:22:45 <Sajeesh> raildo,I will  mail you the design documentation in a couple of days
16:23:05 <raildo> sounds good to me
16:23:34 <Sajeesh> raildo,you had told that you wanted to discuss something regarding project deletion and relocation
16:23:47 <schwicke> #topic design documentation
16:23:53 <raildo> correct
16:25:06 <schwicke> Personally, I think that such features are useful, however, we should review if they are in the first iteration already
16:25:11 <raildo> I talked in #openStack-keystone about the possibility of inclusion of a project in the middle of the hierarchy
16:25:20 <Sajeesh> ok
16:25:26 <raildo> or deletation, or moving
16:25:36 <Sajeesh> ok
16:26:02 <schwicke> I think deletion or moving are technically possible (if there is a use case for this)
16:26:05 <raildo> schwicke: That's exactly what they told me
16:26:17 <schwicke> inserting is tricky
16:26:22 <morganfainberg> there are a lot of security concerns on moving
16:26:28 <Sajeesh> yes
16:26:29 <schwicke> exactly.
16:26:36 <raildo> They find it very complex for this first part.
16:26:43 <raildo> yes
16:26:43 <Sajeesh> sure
16:26:51 <morganfainberg> i'd prefer to add insert/move after we know everything else is working
16:26:52 <morganfainberg> if at all possible
16:27:07 <raildo> So I believe that this initial design will not be allowed to do this.
16:27:08 <schwicke> +1
16:27:10 <morganfainberg> we can then address security concerns and keep a keen eye to that.
16:27:14 <schwicke> correct
16:27:21 <morganfainberg> rather than trying to cram it all in at once
16:27:28 <Sajeesh> +1
16:27:52 <raildo> I'll make that clear at Keystone-spec
16:27:55 <morganfainberg> deletion just is a question of recursive dleete or delete leaves first.
16:28:03 <morganfainberg> and either works for me.
16:28:10 <Sajeesh> right
16:28:23 <morganfainberg> as long as we're clear what is expected.
16:28:26 <schwicke> #agreed insert and move into the tree is not for the initial release
16:28:45 <schwicke> for the deletion part I think we have 2 options
16:28:56 <schwicke> as you say
16:29:11 <schwicke> maybe both can be supported, with the default being not to do a recursive delete
16:29:21 <morganfainberg> sure.
16:29:33 <schwicke> if the user is allowed to then he could eventually explicitly say so
16:29:51 <morganfainberg> as long as we're clear that is what we want in the spec, works for me
16:30:32 <raildo> my fear is that the user can delete recursively without knowing exactly what is below its hierarchy.
16:30:43 <schwicke> indeed
16:30:53 <Sajeesh> yes
16:31:22 <schwicke> The safe option would be to simply disallow recursive removals all together in the first go ...
16:31:47 <schwicke> so you'd have to remove all leaves first manually
16:31:55 <raildo> i agree
16:32:16 <schwicke> one could also argue that we could simply stick to this model, and then have some client tools which would allow for a recursive removal
16:32:17 <Sajeesh> sounds good
16:32:33 <schwicke> later on I mean
16:32:54 <schwicke> Any objections ?
16:32:56 <raildo> now, i believe we can create a function delete  and a function "delete_all" in future
16:33:08 <schwicke> yes.
16:33:19 <schwicke> to be seen if the delete_all is actually needed.
16:33:26 <schwicke> maybe it is not ...
16:33:52 <raildo> +1
16:34:05 <Sajeesh> Means,a project in the middle of a hierachy cannot be deleted ?
16:34:06 <schwicke> so let's go for a simple delete which bails out with "in use" or similar if there are undeleted leaves
16:34:33 <schwicke> sajeesh: it can but you have to remove all leaves before manually :)
16:34:59 <Sajeesh> schwicke, sounds good
16:35:27 <schwicke> #agreed the first version will support a non-recursive delete function which will fail with "in use" or similar if the project to be deleted has children
16:35:42 <Sajeesh> +1
16:36:26 <schwicke> We've been discussion internally as well about the option to  restrict the depth of the tree
16:36:39 <Sajeesh> yes
16:36:46 <schwicke> We'd like to have your input on this
16:37:02 <raildo> that's a good question
16:37:11 <schwicke> #topic do we need an option to restrict the depth of the tree
16:37:41 <schwicke> in our case our users are complex organizations by themselves, and there are often changes in staffing
16:37:41 <raildo> do you have a number in mind? and some justification?
16:37:56 <schwicke> I think we should not impose a default
16:38:16 <Sajeesh> I think it should be configurable
16:38:23 <raildo> +1
16:38:23 <schwicke> what we were thinking of is to have a configuration option eg in nova.conf which is optional and gives the maximum depth
16:38:40 <schwicke> default could be unlimited.
16:39:20 <raildo> but if the hierarchy will be in keystone, i believe that this configuration should be in keystone.conf
16:39:30 <schwicke> correct
16:39:34 <Sajeesh> yes
16:39:42 <schwicke> of course :)
16:40:13 <schwicke> Thinking of when to do that I believe that this feature should be present from the beginning
16:40:33 <schwicke> Once the tree is there it will be hard to get rid of it again, from experience ...
16:40:45 <Sajeesh> true
16:41:05 <raildo> I think we can evaluate the performance of queries of this hierarchy. If we do not have a big delay, I agree to be unlimited.
16:41:28 <raildo> we can begin to unlimited and evaluate this in the future
16:41:36 <schwicke> true.
16:41:42 <Sajeesh> ok
16:41:51 <morganfainberg> please make the depth limit an option out the door
16:42:05 <morganfainberg> you can default it to unlimited but i'd like to have it available out the gate
16:42:21 <morganfainberg> but might be useful to have that tuning option to start
16:42:27 <schwicke> hmm
16:42:42 <schwicke> maybe unlimited is not such a good default at the end :)
16:43:16 <schwicke> for the reason I mentioned above ...
16:43:51 <morganfainberg> yah
16:44:00 <schwicke> eventually it is more clever to actually have a fairly strict limit on it.
16:44:07 <Sajeesh> default can be a reasonable number
16:44:08 <schwicke> It is easy to grow but hard to shrink ...
16:44:20 <morganfainberg> schwicke, i like opting for overly strict to start (3?5?) and then expand
16:44:24 <morganfainberg> i would absolutely make it a config option though
16:44:40 <schwicke> +1
16:45:03 <raildo> +1
16:45:07 <Sajeesh> +1
16:45:28 <schwicke> #agreed as of the first release we should have a configuration option allowing to restrict the depth of the tree with a reasonable default of 3 or 5
16:46:04 <Sajeesh> raildo,in the current implementation,whether a user having the role in the parent will be having the same role in all the child projects,which can only be overridden
16:46:33 <schwicke> #topic role inheritance
16:46:34 <Sajeesh> user having a role in the parent
16:47:35 <schwicke> we've had a chat with Tim Bell who told us that by default user rights are inherited from above in the tree
16:48:04 <schwicke> so by default the cloud admin or whoever is on top of the tree has full power on all the leaves
16:48:33 <schwicke> The question now was if there is a possiblity to override this. There are use cases where this is not actually wanted, eg for security reasons.
16:49:00 <schwicke> raildo: is it possible to override that in keystone ?
16:49:32 <raildo> Inherited roles already operate normally today, But work in relation to domains, ie, a user who has role on a domain, will be inherited to all projects within this domain
16:50:02 <Sajeesh> It may not be acceptable for organizations who subscribe resource from outside vendor and also sensitive organizations
16:50:45 <raildo> except the cloud admin. At the time I discussed with vish to create an exception for him.
16:51:02 <Sajeesh> ok
16:51:03 <raildo> just to be careful with the security
16:51:10 <Sajeesh> ok
16:51:35 <schwicke> so the cloud admin will always have super user right ?
16:52:25 <raildo> but a role associated with a project on a higher level, you can get a token for a project from a level below. since this role is inheritable.
16:52:49 <schwicke> ok
16:53:13 <Sajeesh> raildo,whether a lower level project can override it
16:53:14 <raildo> The idea is to make the cloud admin does not have access (by default) to all projects. he just "manage" the cloud.
16:53:55 <schwicke> makes sense to me
16:53:56 <raildo> I did not think that possibility to override a role.
16:54:29 <Sajeesh> ok
16:54:29 <schwicke> we can surely postpone such a feature to a later release
16:54:52 <raildo> we can better discuss this in another meeting, or email.
16:54:57 <Sajeesh> ok
16:54:59 <schwicke> ok
16:55:20 <raildo> The time of the meeting today is almost over.
16:55:25 <schwicke> #agreed to rediscuss the inheritance in a later meeting or via e-mail
16:55:27 <schwicke> yes
16:55:30 <Sajeesh> ok
16:55:40 <schwicke> #action Sajeesh to complete the design draft and send via e-amil
16:55:47 <Sajeesh> ok
16:55:56 <schwicke> let's meet again in a week from now and see where we are
16:56:03 <Sajeesh> ok
16:56:04 <raildo> great
16:56:08 <schwicke> AOB?
16:56:19 <raildo> I believe that the meeting was very productive
16:56:19 <Sajeesh> I will mail raildo
16:56:34 <schwicke> +1
16:56:38 <Sajeesh> very much
16:56:42 <schwicke> so see you next week then!
16:56:46 <Sajeesh> ok
16:56:48 <schwicke> #endmeeting