16:02:18 #startmeeting hierarchical_multitenancy 16:02:19 Meeting started Fri Jul 18 16:02:18 2014 UTC and is due to finish in 60 minutes. The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:23 The meeting name has been set to 'hierarchical_multitenancy' 16:02:58 I have 3 items which I think we need to discuss today 16:03:30 Timelines for Juno (are we on track?), authorization model for quota and the meeting slot 16:04:12 #topic time lines 16:04:57 I thought the spec about multitenancy hierarchical should have been approved. 16:04:57 are we stil in time for the next OS release ? 16:05:23 but otherwise the implementation is well underway. 16:06:59 I talked to morganfainberg in meeting the keystone Tuesday. Like me, he thinks reasonable, that hierarchical multitenancy still in Juno. 16:07:11 ok. 16:07:45 nevertheless we need to keep an eye on this. Will check with Nirbhay for the Nova part 16:08:20 #INFO no worries for now. 16:08:22 I hope in the next days the spec is approved. 16:08:55 #topic authorization schema: do we need/keep parent info in the ticket ? 16:09:11 so next topic, and this one is rather important I think 16:09:35 We had some disucssions via e-mail with Sajeesh about the mechanisms for authorization. 16:09:51 I had sent around a wrap up of how I think it should be done 16:10:10 Did you have a chance to think about this ? 16:10:51 schwicke: I read your email and I agree with your design. 16:11:21 hi 16:11:32 Hi, Nirbhay! 16:11:37 Nirbhay_: hi 16:11:38 hi 16:11:50 we just switched to the discussions we had with Sajeesh 16:11:56 hi to all 16:11:58 ok 16:12:09 so in the model I propose there is no need to have any knowledge about the parent in the keystone ticket. 16:12:20 yes 16:12:46 i agree with it.. 16:13:04 Sajeesh thinks that this model is less flexible than his model where the keystone token contains knowledge of the parent 16:13:45 but is simpler. 16:14:09 schwicke, be careful about adding extra data into the keystone token 16:14:10 schwicke, the keystone tokens already have *size* issues 16:14:10 yeah it is simple and easy for end user to understand.. 16:15:00 morganfainberg: that is why I want to clarify this and make a decision 16:15:08 it's not a lot more data (if it's only one parent up), but... all data counts 16:15:14 if it's the whole tree, i say no 16:15:51 I'm very much in favor of not having the parent data in the ticket and do it the way I proposed 16:16:10 schwicke, ++ ok, *just jumping in on things that worry me* :) 16:16:16 the only use case which is covered by Sajeesh model can be covered on the client side 16:17:08 * morganfainberg has to run, i'll catch up with raildo on any specific topics that result from this that i need to know about / sync up with folks about 16:17:13 or anyone can find me in #openstack-keystone later today :) 16:17:19 I think we agreed to use the schwicke model and lessen the impact on the token. 16:17:39 any objections anyone ? 16:17:46 morganfainberg: ok :) 16:17:52 no 16:17:53 if not we decide on the model as proposed by me 16:18:28 #agreed we'll implement the simple auth model which does not require knowledge of the parent 16:18:49 Great. I think for the design we are done, aren't we ? 16:18:54 i think we should confirm it with sajeesh that there is issue in implementing schwicke model 16:18:59 schwicke: yes 16:19:10 yes, we'll need to check with him 16:19:25 I think we'll have to apply a few code changes 16:19:40 #action review code from Sajeesh in view of the decided model 16:19:56 ok 16:20:29 Nirbhay: that is something you can do as well 16:20:34 ok 16:20:37 i will 16:20:58 Great. So last topic for today is the meeting slot - unless you have anything else on this topic 16:21:10 #topic meeting slot 16:21:22 raildo: thanks for the proposal 16:21:29 schwicke: you have seen the sajeesh's blueprint is freeze? 16:21:46 nope, is it ? 16:21:55 schwicke: yes 16:22:15 ok, we need to check with him 16:23:00 AFAIK he has implemented his model. With a bit of luck both are supported ... 16:23:08 I went to the meeting yesterday of the Nova, and it was decided that it should send an email to the mailing list, asking for an "exception" to be released in Juno. 16:23:43 to openstack-dev ? 16:23:49 or the nova list ? 16:24:12 I think in the openstack-dev 16:24:33 but you can confirm with him. 16:24:39 will do 16:24:45 #link https://etherpad.openstack.org/p/nova-juno-spec-priorities 16:25:57 Sorry to bother the previous topic, I thought it important to inform that. 16:27:12 yes, definitely 16:27:13 thansk 16:28:35 talking about meeting slot, the time 1300 UTC(on another day) would be good for you? 16:29:06 that's 15pm here. Fine by me. 16:29:10 Not sure about BARC ? 16:29:34 Not for BARC 16:29:53 Nirbhay_: any suggestions? 16:30:10 yes 16:31:44 tell us :) 16:31:49 not in between 1100UTC to 1400 UTC 16:32:23 14:00 UTC would be ok ? 16:32:55 14:30 would be ok 16:33:00 sound good to me 16:33:12 ok for me as well 16:33:16 Which day? 16:33:17 +1 14:30 16:33:33 Thursday is bad for me 16:34:03 Tue or Wed 16:35:08 wednesday, 14:30UTC? 16:35:32 is good for everyone? 16:35:46 yes 16:36:15 ok. Need to check still if there is a clash with another meeting 16:36:27 ok 16:36:47 I checked, no have meeting in this time. 16:36:57 https://wiki.openstack.org/wiki/Meetings 16:37:15 xen api is at 15:00 UTC 16:37:28 are 30 min enough for us ? 16:37:55 may be 16:38:03 I believe that we can test. 16:38:13 mostly discussion are on email 16:38:48 ok, then let's go for that 16:39:14 ok 16:39:18 ok 16:39:19 #agreed new meeting slot Wednesday 14:30 UTC i 16:39:31 agreed 16:39:37 +1 16:40:10 I'll update the meeting page 16:40:17 ok 16:41:23 I have to leave now, bye guys 16:41:33 done 16:41:40 I think we are done 16:41:46 AOB ? 16:41:48 done 16:41:52 #endmeeting