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