16:01:29 #startmeeting hierarchical_multitenancy 16:01:30 Meeting started Fri Jul 17 16:01:29 2015 UTC and is due to finish in 60 minutes. The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:32 o/ 16:01:33 The meeting name has been set to 'hierarchical_multitenancy' 16:01:36 o/ 16:01:38 Hi, all 16:01:40 \o 16:01:58 schwicke, hi :) 16:02:00 hello all 16:02:20 Raildo: thanks for running the meeting last Friday 16:02:28 schwicke: np :) 16:03:20 #topic random coordination stuff 16:03:41 vilobhmm: I have just sent you an invitation via skype 16:04:01 did you receive it ? I'd like to add you to the group chat 16:04:09 hope I got it right 16:04:31 I haven't 16:04:54 vilobhmm, what is your skype id? 16:05:34 what id schwicke did you sent it to 16:05:42 sent it to vilobh 16:05:44 not you? 16:05:49 meshramvilobh 16:05:56 no schwicke 16:06:00 its "meshramvilobh" 16:06:05 please try again 16:06:43 just did 16:07:22 did you get it this time ? 16:07:35 yes 16:07:40 accepted :) thanks 16:08:26 ok, I just added you. So that's done :) 16:08:30 yes 16:09:13 On the same organisational topic: Sajeesh is sorry he cannot attend today. It is the first birthday of his sun. 16:09:29 oh okay 16:09:33 np 16:09:39 let me start with cinder update then 16:09:40 schwicke, np at all 16:09:41 son I mean 16:09:45 it's a good reason :) 16:09:52 yes, indeed :) 16:09:58 So let's try without him 16:10:06 sure 16:10:22 As far as I see beyond this meeting we have only one opportunity before the code freeze 16:10:26 which is next friday, right ? 16:10:36 yes 16:10:38 yes 16:10:42 for nova the code free is july 30th 16:10:43 we need to get things moving forward 16:10:47 I'll be on holiday myself from Sunday on so unlikely that I will be able to share the meeting on Friday 16:11:05 There should be a meeting nevertheless. 16:11:09 ++ 16:11:25 raildo_m : do we have a common websit for openstack which shares this details for deadline for various projects 16:11:26 Yes. We need to avoid the code freeze exception exercise this time 16:12:21 vilobhmm: I only know that: https://wiki.openstack.org/wiki/Liberty_Release_Schedule 16:13:04 alrite 16:13:19 so from cinder side ericsonsantos and myself we tried to move https://review.openstack.org/#/c/143645/ forward 16:13:25 by reviewing it 16:13:34 #topic review of action items 16:13:47 which in last meeting we thought would be beneficial for cinder nested quota 16:14:27 will continue doing that 16:14:46 apart from that someone from us need to talk to keystone folks 16:14:46 ok 16:14:47 what is missing in this patch in order to merge is test the keystoneclient instantiation 16:15:07 ericksonsantos : yes…if we can help here it will be nice 16:15:13 vilobhmm, sure 16:15:49 someone from us need to talk to keystone folks as we discussed in last meeting 16:16:01 as interaction with keystone is something common for cinder/nova 16:16:15 and hence don't want that to be a blocker moving ahead 16:16:36 vilobhmm, I have found an existing bug which may impact on nested quota driver 16:16:38 as the policy.json changes that will be done in cinder and nova will depend on the logic exposed by keystone 16:16:38 see https://review.openstack.org/#/c/139610/ 16:17:29 vilobhmm: due the deadline, I think that we need to follow the current approach... 16:17:45 when doing a cinder quota-defults , this tenant_id is being ignored by cinder 16:18:04 vilobhmm: liberty-2 is really closer to try change something in the keystone side now... 16:18:13 raildo_m : ok 16:18:21 so what do you propose raildo_m 16:18:47 maybe comment on this patch ? 16:19:09 schwicke, will do 16:19:13 ericksonsantos : thanks…will check it out! 16:19:35 #action erickonsantos will comment on https://review.openstack.org/#/c/139610/ 16:19:36 I think that we can keep following this approach, that sajeesh are doing here: https://review.openstack.org/#/c/182522/ 16:19:47 vilobhmm: ^ 16:20:48 ok but if such role or user are not created in keystone will it still work ? 16:20:53 raildo_m : ^^ 16:21:23 I think it will work fine if we just let policy.json as it is now 16:21:46 vilobhmm: unfortunately, we need to handle with this problem :( 16:21:49 schwicke, all : sorry going in lots of details since this is something important and we need to get this resolved 16:22:01 vilobhmm: writing in the docs, os something like that 16:22:07 that's ok 16:22:27 raildo_m, ericksonsantos : ok 16:23:21 so what is the conclusion? 16:23:25 then for liberty-2 lets keep it the way https://review.openstack.org/#/c/182522/ for both cinder/nova respectively and have some DocImpact section updated ….going ahead we can start the conversation with keystone folks 16:23:34 schwicke : ^^ 16:23:42 vilobhmm: ++ 16:23:51 ok 16:24:06 #agreed for liberty-2 lets keep it the way https://review.openstack.org/#/c/182522/ for both cinder/nova respectively and have some DocImpact section updated ….going ahead we can start the conversation with keystone folk 16:24:14 +1 16:24:28 so who is going to contact the keyston folks ? 16:24:39 should be done asap as well 16:25:38 schwicke, I'm not getting the point, what do we want from them? 16:25:59 keystone folks are in the keystone midcycle today... I think that I can contact us on monday 16:27:39 raildo_m : sure… 16:27:54 in the policy.json, I think if we have a rule like: role:admin and project_id:%(project_id)s" 16:28:00 it will work, right? 16:29:27 raildo_m: what are the basic questions we need to get answered by the keystone folks ? 16:30:26 #action Raildo will contact the keystone folks and report in the skype group chat about the outcome 16:30:28 schwicke: I think that the main question is if we can use the "nova service role" to get the subprojects 16:30:30 :) 16:30:40 Ah 16:30:52 if we can do this, we don't need new roles in the nova/cinder side 16:31:21 raildo_m, hmm.. I see 16:31:23 +1 16:31:43 just wonder if there are any security related issues if we do that 16:32:34 maybe you can discuss with them if they can see any issues with that 16:32:48 ok 16:32:48 schwicke, ++ 16:33:12 yes…I guess we can find many new things once we start discussing with keystone folks 16:33:28 sure 16:33:40 lets move on … 16:33:45 yes. 16:34:10 we had: vilobhmm and ericksonsantos will make sure this patch 16:34:10 https://review.openstack.org/#/c/143645/ proceeds and gets merged 16:34:20 its not yet merged as far as I can see 16:34:31 +1 16:34:57 for cinder nested quota driver changes (final changes as i have 2 patches merged already) should be done by next week…this week was caught up with unit test and some work internally 16:34:59 no, it's not. This patch needs at least one more test. 16:35:21 ok 16:35:51 let's review next week 16:35:56 alrite 16:36:11 #action vilobhmm and ericksonsantos will make sure this patch 16:36:11 https://review.openstack.org/#/c/143645/ proceeds and gets merged 16:36:22 sure 16:36:26 will do 16:36:27 we had: raildo wiil keep working to fix the #link 16:36:27 https://review.openstack.org/#/c/182140/ 16:36:55 this is a tricky one 16:37:15 I'm debugging this to check what is the actual difference from the keypair and security group APIs 16:37:34 that is making the policy enforcement to be done in the project_id of the context 16:37:41 not on the project_id of the URL 16:38:33 ++ 16:39:54 I answered the last sajeesh email with the two possibly solutions for this 16:40:08 he's very much in favor of a different solution 16:40:32 the issue of his solution 16:40:42 is that each nova API call would trigger a keystone API call 16:40:44 I think we don't need to remove that checking 16:41:09 and we also would require that the user has the role in keystone to perform a get_project() 16:41:12 vilobhmm, we have the same checking on the cinder side 16:41:17 what can not be the case 16:42:31 the second solution is the one that Sajeesh started to implement, right ? 16:43:29 ericksonsantos : I am not sure this time 16:43:32 the user needs to have the right to do the get_project on which of the projects ? On the parent ? 16:43:59 in the target project 16:44:06 vilobhmm, https://github.com/openstack/cinder/blob/master/cinder/api/openstack/wsgi.py#L1003-L1007 16:45:35 in which situation would the user not have the rights on the target project ? 16:46:02 schwicke, it is not common 16:46:02 but can happen 16:46:14 usually parent should have the right to get/update the target project ; target being the child project 16:46:16 needs careful thinking 16:46:20 schwikce : ^^ 16:46:53 stupid question : what is the problem with the other solution ? 16:46:53 if in keystone's policy file we have that the Member role is authorized to perform get_project() 16:47:10 and in nova the user updating the quota has the _member_ role 16:47:21 it is a possible situation 16:47:32 yes 16:49:12 Sajeesh said in the group chat that he'd upload the code on Sunday when he's back in Mumbai 16:50:04 o/ 16:50:15 I suggest we wait for what he has done and continue to evaluate the solution proposed by rodrigods 16:50:38 is that an option ? 16:50:41 will write an email explaining my solution 16:50:47 actually, abrito's solution 16:50:47 sure 16:50:55 see if you all agree 16:50:55 ah, sorry 16:51:22 rodrigods : If you can document both the approches and the problem they will solve with an example as we dicsused here 16:51:47 vilobhmm, absolutely 16:51:49 we can discuss and have a conclusion over email by monday 16:51:59 or if needed get on a skype call 16:52:07 ++ 16:52:09 thanks 16:52:11 #action review Sajeeshs code for https://review.openstack.org/#/c/182140/ and continue to evaluate alternative solution by Abrito 16:52:33 good idea 16:53:22 #action document and discuss implications of both solution by Monday 16:53:48 Sajeesh asked me to action item him 16:53:54 #action Rectifying the context checking of https://review.openstack.org/#/c/182140. 16:54:10 that's for Sajeesh :) 16:55:04 he asks for help on implementing more test cases 16:55:21 I wonder if there are some synergies between nova and cinder, something that can be re-used ? 16:55:43 #action (all) Adding more test cases for nested quota. 16:56:25 are there any free resources to help on this ? 16:56:53 time is running out 16:57:13 I think ericksonsantos is writing tests for Cinder 16:57:13 schwicke, I think the steps in order to get it done are almost the same. So, sure, code can be re-used. 16:57:17 some of them can be reused 16:57:34 but let's not create too much tests 16:57:37 schwicke : agree with ericsonsantos 16:57:50 repeating the same thing 16:58:02 in HMT in Keystone we had just a few tests that covered all situations 16:58:08 lets just focus on basic get/update/delete use cases 16:58:09 rodrigods, sure 16:58:16 ok 16:58:28 sure 16:58:43 ++ 16:58:47 #agreed focus on the basic get/update/delete use cases for tests 16:59:13 still, it should be review what is missing for nova and already there for cinder and then copy and paste if needed 16:59:31 ++ 16:59:33 and vice versa 16:59:34 can discuss this over skype 16:59:37 ++ 16:59:40 exactly 17:00:03 #action (all) import and exchange missing tests for cinder and nova 17:00:23 the last thing are the still failing tests after monkey patching 17:00:31 and jump on to all the reviews posted by our team irrespective of nova or cinder :) 17:00:42 #action sajeesh will check the 3 still failing tests after monkey patching 17:01:03 let's follow up on skype and/or email 17:01:09 we have to leave the room 17:01:15 alrite 17:01:16 sure 17:01:17 yep 17:01:17 sure 17:01:19 bye guys 17:01:20 p/ 17:01:22 see you 17:01:22 o/ 17:01:24 :) 17:01:26 bye 17:01:28 #endmeeting