16:05:20 #startmeeting Hierarchical Multitenancy 16:05:21 Meeting started Fri Apr 4 16:05:20 2014 UTC and is due to finish in 60 minutes. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:24 The meeting name has been set to 'hierarchical_multitenancy' 16:06:28 has anyone looked at wiki.openstack.org/wiki/HierarchicalMultitenancy 16:06:42 ? 16:06:56 #link http://wiki.openstack.org/wiki/HierarchicalMultitenancy 16:07:05 vishy: I read this week 16:07:15 any comments or changes? 16:07:43 vishy: about it "Roles will be inherited down the project hierarchy tree" I was wondering how is the implementation of the inherited roles in poc. Is there anyone implementing? 16:07:56 in "Keystone Changes" 16:08:15 raildo: hmm i thought that it was done in the keystone patch 16:08:17 let me look 16:09:06 ok 16:09:25 ah no i was wrong 16:09:35 it appears no one has implemented that in the poc 16:10:21 vishy: I was interested in implementing 16:10:45 if you want to take tellesnobrega’s code and add in role inheritance it doesn’t look too hard 16:11:09 I was reading and thinking about the design of the solution and was with out a doubt. 16:11:15 you could also add in passing both hierarchical_ids and hierarchical_names and separate with ascii 0x30 if you want 16:11:26 https://docs.google.com/document/d/1mYLb_goIVK3VKrITqyKLGHTh7t_UEjgZTBx-QTz__Mc/edit?usp=sharing 16:13:03 If you can have a look, summarizing my question is that it should will be automatic inheritance of all the roles of a parent project, or if the user will choose which roles are inherited. 16:13:35 raildo: that makes sense 16:13:52 having an optional inherited flag 16:14:34 #link https://docs.google.com/document/d/1mYLb_goIVK3VKrITqyKLGHTh7t_UEjgZTBx-QTz__Mc/edit?usp=sharing 16:14:50 vishy: Then the user must add the roles that are inherited, right? 16:15:06 #info raildo suggests an inherited flag for roles which would control whether the role is inherited down the tree. 16:16:23 added a note to the wiki 16:16:42 ok 16:16:50 vishy: I'll start with the implementation and hope to have something done for next week. =] 16:17:06 #action raildo to implement inherited roles in the poc 16:17:15 #topic design summit 16:17:35 I proposed a session for cross project implementations 16:17:39 #link http://summit.openstack.org/cfp/details/219 16:17:53 there are also two other related sessions 16:18:01 sounds good to me 16:18:19 #link http://summit.openstack.org/cfp/details/62 16:18:23 which is for keystone 16:18:39 #link http://summit.openstack.org/cfp/details/58 16:18:44 for nova (about domains) 16:19:30 i also made some notes on there linking them to each other 16:19:33 the domain one might end up spending time on hierarchical projects as well 16:19:49 depending on the consensus about whether projects other than keystone should know about domains 16:20:22 raildo: i like your suggestion about non-inheritance 16:20:30 i’m thinking specifically about a role like CloudAdmin 16:20:59 I could potentially see situations where the CloudAdmin could do special things that aren’t about a given resource 16:21:29 or a resource that isn’t tenant specific like create shared provider networks in neutron 16:21:45 so for safety reasons it might be good to have CloudAdmin not inherit down the tree 16:22:05 +1 16:22:15 where as a general capability like a role for attach_floating_ip 16:22:21 you would probably want that to inherit 16:23:05 ok good 16:23:11 anything else? 16:23:15 I believe that if a CloudAdmin will make any changes to a project, simply add a new role as a ProjectAdmin 16:24:24 for me, it's done 16:26:16 ok 16:26:19 #endmeeting