16:04:03 <schwicke> #startmeeting hierarchical_multitenancy
16:04:04 <openstack> Meeting started Fri Jul 11 16:04:03 2014 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:07 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:04:41 <schwicke> thanks for the lively off-line discussions :)
16:04:50 <schwicke> I think that was very usefull
16:04:58 <nirbhay_> yes
16:05:10 <schwicke> Maybe we should start then with the design document
16:05:20 <raildo> yes
16:05:28 <sajeesh> ok
16:05:33 <schwicke> #topic design discussions
16:06:27 <schwicke> So let's document the example here. We have a very simple tree A->B->C so one project at each level with A being the root
16:07:17 <schwicke> then we define "used Quota" = the resources used in the current project
16:07:22 <sajeesh> ok
16:07:27 <nirbhay_> ok
16:07:43 <schwicke> Limit: the maximum  for the current project
16:07:52 <sajeesh> yes
16:08:15 <schwicke> Allocatd: the quote allocated (or delegated) to the children (summed)
16:08:23 <schwicke> A: free_quota= A :limit - (A : used + A: allocated)
16:08:24 <nirbhay_> yes
16:08:25 <sajeesh> yes
16:08:30 <schwicke> B:free_quota=B:limit - (B:used + B: allocated)
16:08:36 <schwicke> C:free_quota=C:limit - (C:used)
16:08:47 <nirbhay_> done
16:08:58 <raildo> +1
16:09:03 <sajeesh> +1
16:09:06 <nirbhay_> +1
16:09:12 <schwicke> So as far as I can see everbody is happy with this model
16:09:18 <schwicke> right ?
16:09:21 <nirbhay_> yes
16:09:22 <sajeesh> yes
16:09:27 <rodrigods> yeah
16:09:37 <raildo> yes
16:09:44 <sajeesh> I was afraid that I had to rewrite my code
16:09:48 <sajeesh> :-)
16:10:03 <rodrigods> hehe
16:10:15 <raildo> good luck for you :)
16:10:25 <sajeesh> thanks raildo :-)
16:10:30 <schwicke> #agreed to use the a model with minimal coupling between the projects
16:11:52 <sajeesh> raildo ,whether the token will contain the parent hierarchy and list of child projects
16:11:53 <schwicke> in the last meeting we started to talk about the roles as well
16:12:19 <schwicke> yes, let's discuss that first
16:12:26 <nirbhay_> ok
16:13:00 <nirbhay_> i think only admin should be able to change quota allocations
16:13:02 <raildo> sajeesh: yes, we have to make a modification to include the top of the hierarchy in the token
16:13:26 <sajeesh> ok raildo
16:14:08 <sajeesh> raildo,what will be the format of the list of child projects ?
16:15:43 <raildo> "hierarchical_ids": "openstack.8a4ebcf44ebc47e0b98d3d5780c1f71a.de2a7135b01344cd82a02117c005ce47",
16:16:13 <raildo> a list of ids, from the top to the project.
16:16:21 <raildo> a string*
16:16:31 <sajeesh> ok raildo ..that will do
16:16:54 <raildo> a string with the concatenation of ids separated by a dot.
16:17:28 <schwicke> is everybody happy with that ?
16:17:35 <nirbhay_> it is upto project in which user has same role or up to root of tree...
16:18:10 <raildo> for the children, I think about doing similar returning a string for each child.
16:18:21 <nirbhay_> ok
16:18:33 <sajeesh> raildo,for children that will do
16:19:07 <sajeesh> it can be string with dot delimiter
16:19:20 <raildo> nirbhay_: to the top of the tree.
16:19:23 <nirbhay_> yes for children it is ok
16:19:50 <raildo> nirbhay_: as to update the quota, I have to go over the top.
16:20:04 <nirbhay_> yes
16:20:11 <sajeesh> raildo, I think we have to see the roles also
16:20:41 <nirbhay_> for that only u need to go up to the project in which user has same role..
16:20:48 <raildo> sajeesh: the token already contains the roles relating to the user.
16:20:59 <nirbhay_> so how that information will be available with token
16:21:36 <raildo> "roles": [             {                 "id": "c60f0d7461354749ae8ac8bace3e35c5",                 "name": "admin"             }         ]
16:21:41 <raildo> something like that
16:21:55 <sajeesh> Raildo ,If you are giving me up to the top also no problem......I will filter it based on the roles
16:22:08 <nirbhay_> ok
16:22:14 <rodrigods> you don't need to walk the tree to updated the used quota, with the proposed solution
16:22:43 <rodrigods> so, since a user has a role in a project below the hierarchy, it can create instances in this project and the whole tree quota will be seemly updated
16:23:50 <nirbhay_> i agree for used quota we need not to go up or down the tree..
16:24:25 <sajeesh> raildo,whether the role info contains role-id-user-id-project-id mapping....I am sorry if the doubt is misplaced
16:25:05 <rodrigods> yeah, and for limit's updates, it need to check if the parent has enough free limit. it will never be able to change the parent's limit.
16:25:12 <rodrigods> this is how i see it working
16:25:31 <rodrigods> free_limit = limit - allocated
16:26:41 <raildo> sajeesh: Yes, the token contains the link between role, user, projecet (in the case now, the inherited roles for your children)
16:26:49 <raildo> project*
16:27:16 <sajeesh> ok raildo,that seems very useful ++1
16:27:22 <schwicke> I think we need to have a short discussion about who can do what where
16:27:41 <nirbhay_> agreed
16:27:59 <schwicke> The way I see it working is that there are 3 roles: the cloud admin, the project admin and a user role
16:28:12 <nirbhay_> ok
16:28:31 <schwicke> the cloud admin is a super user
16:28:50 <schwicke> in the sense that he is an admin of the root project
16:29:32 <schwicke> The cloud admin is the only one who can change the quota of the root projec
16:29:39 <nirbhay_> ok
16:29:45 <sajeesh> ok
16:30:35 <schwicke> A normal admin can create projects inside his project, set their quota, and nomincate the admins of the child projects which he creates
16:31:00 <nirbhay_> agreed
16:31:03 <schwicke> A normal admin cannot change the quota of the project of which he is an admin IMO
16:31:09 <sajeesh> ok
16:31:25 <schwicke> if we do that, then I think there is no need to check the quota of the parent, is there ?
16:31:44 <schwicke> because only the admin of the parent can change the quota of a project ...
16:32:02 <schwicke> ups, I think I should update the topic ...
16:32:07 <schwicke> #topic roles
16:32:08 <raildo> i agree
16:32:17 <sajeesh> shwicke ,we can think about iy
16:32:22 <sajeesh> shwicke ,we can think about it
16:32:54 <sajeesh> raildo,if possible can you please send a  small design documentation regarding role inheritance...I doubt whether I am having a complete picture
16:32:58 <schwicke> sajeesh: do you have any doubts about this ? I think it is very important to agree on this nowish
16:33:20 <raildo> sajeesh: ok
16:33:25 <sajeesh> shwicke,I will think about it
16:33:34 <sajeesh> raildo ,thanks
16:34:02 <sajeesh> shwicke,I will discuss that matter after getting raildo's document
16:35:06 <sajeesh> schwicke,yes I am having doubts
16:35:23 <schwicke> sajeesh: tell me :)
16:35:59 <raildo> This comes at a point that I wanted to discuss, inherited roles currently only work for domains.  http://docs.openstack.org/api/openstack-identity-service/3/content/api-1.html
16:36:00 <sajeesh> schwicke,I will tell after reading the design documentation of raildo :-)
16:36:55 <raildo> we have to implement the API about inherited roles for projects.
16:37:02 <sajeesh> ok
16:37:20 <nirbhay_> ok
16:37:25 <schwicke> sure
16:37:52 <schwicke> raildo: do you need help ? Maybe nirbhay could get involved in that ?
16:38:05 <raildo> I believe that the effort is not large, as it will be very similar to what already works today.
16:38:21 <schwicke> #link   http://docs.openstack.org/api/openstack-identity-service/3/content/api-1.html
16:39:21 <raildo> The folks at my team will develop this in the coming weeks but any problem, I bring here to the meeting.
16:39:28 <sajeesh> ok
16:39:32 <nirbhay_> ok
16:39:35 <schwicke> ok
16:40:05 <schwicke> #action Raildo et al to implement the API for inherited roles for projects
16:41:20 <sajeesh> shwicke...we need to have a offline discussion on role inheritance
16:41:30 <schwicke> ok, no problem
16:41:56 <schwicke> #action discuss role inheritenance offline. Schwicke to re-send the proposal via e-mail
16:42:33 <raildo> Moreover, we are implementing using SQL as the backend, and discussing with the Keystone folks, we decided that we will not give support for LDAP.
16:42:54 <sajeesh> ok
16:42:56 <raildo> I'll include it in the spec.
16:43:02 <nirbhay_> ok
16:43:07 <schwicke> hmmm....
16:43:45 <schwicke> ldap support would have been for defining the roles ?
16:44:01 <rodrigods> to store the hierarchy, i think
16:44:13 <schwicke> ah, ok
16:44:29 <raildo> " <morganfainberg>  Ldap assignment is _very_ limited compared to the sql assignment backend"
16:44:42 <raildo> "<bknudson> If the question is do we really need to support ldap for hierarchical multitenancy, I would say let's not do it."
16:45:17 <raildo> So we will work only with SQL storage.
16:45:33 <schwicke> ok
16:45:49 <schwicke> in which meeting is that discussed by the way ?
16:45:49 <bknudson> ldap assignment still needs to work
16:46:06 <bknudson> but would expect it to be with single level projects
16:46:22 <raildo> bknudson: ok
16:47:33 <bknudson> and if someone really wants it for ldap they can do the work
16:48:59 <schwicke> ok, thanks for the info
16:50:13 <schwicke> anything else on this topic ?
16:50:22 <raildo> no
16:50:35 <schwicke> ok, then let's move on
16:50:39 <sajeesh> ok
16:50:43 <nirbhay_> ok
16:51:10 <schwicke> Last week we briefly discussed if we can do the meeting a bit earlier
16:51:18 <sajeesh> yes
16:51:22 <nirbhay_> yes
16:51:56 <schwicke> one hour earlier would be fine for me but I think that having it still earlier is difficult from India, right ?
16:52:08 <sajeesh> yes
16:53:08 <schwicke> would 17MEST be fine ?
16:53:25 <sajeesh> ok for me
16:53:26 <nirbhay_> ok fine
16:53:39 <schwicke> need to check though if that clashes with any other meeting
16:54:03 <raildo> ok
16:54:20 <schwicke> that would be 15UTC, correct ?
16:54:46 <raildo> yes
16:54:51 <schwicke> Clashes with blazar I'm afraid
16:55:51 <raildo> 14UTC have another meeting?
16:56:40 <schwicke> 14UTC is not good far Sajeesh
16:56:43 <sajeesh> 14 UTC is too early for me
16:56:50 <raildo> ok
16:56:50 <schwicke> s/far/for/
16:58:04 <raildo> 16UTC, 17? :P
16:58:49 <schwicke> err... looks indeed as if we have to keep it as it is for now.
16:59:08 <schwicke> meeting time is over.
16:59:19 <raildo> ok
16:59:21 <schwicke> so let's keep it for now as it is
16:59:40 <schwicke> #agreed keep the meeting slot as it is now for the time being
16:59:52 <schwicke> #endmeeting