16:01:09 #startmeeting hierarchical_multitenancy 16:01:10 Meeting started Fri Jun 19 16:01:09 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:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:14 The meeting name has been set to 'hierarchical_multitenancy' 16:01:18 Hi all! 16:01:21 hi schwicke :) 16:01:34 nice to see you back1 16:01:35 Hi :) 16:01:52 Sorry I had to drop out for a while for various personal and professional reasons 16:01:54 :) 16:02:08 schwicke, nice to see you back too :) 16:02:11 o/ 16:02:21 hello all 16:02:24 hi, Belmiro! Good to have you here as well 16:02:28 hi raildo 16:02:34 hi belmiro 16:02:36 Hi, Raildo, Vilob! 16:02:45 hi vilob 16:02:57 hello schwicke! hi sajeesh ! :) 16:03:07 so if we have everyone should we start 16:03:11 hey sajeesh 16:03:13 ok 16:03:17 I had circulated a set of topics to be discussed. I didn't get much feedback so lets just start 16:03:32 #topic Default quota patch - root level project gets default values set in cinder.conf 16:03:46 schwicke : I am working on these changes 16:03:57 the question here was if we can do the same for nova 16:04:00 will get the patch out EOD 16:04:09 great! 16:04:14 nice 16:04:20 this is for cinder, isn't it ? 16:04:20 schwicke it is done and I have uploaded the patch 16:04:34 very good. So that can be ticket off. 16:04:42 I mean in nova , it is done 16:04:55 sajeesh: very good! 16:05:04 https://review.openstack.org/151677 16:05:07 Did you solve your problem vilobhmm ? 16:05:08 thanks...please review it 16:05:11 patch is nova under review 16:05:52 yes 16:06:07 https://review.openstack.org/#/c/149828/ 16:06:25 ericsonsantos : I think just adding a classification of whether a project is a sub-project or not is not sufficient IMHO https://github.com/openstack/cinder/blob/master/cinder/quota.py#L106 16:06:51 sajeesh's default quota patch : https://review.openstack.org/151677 16:06:59 sajessh's nested quota driver patch : https://review.openstack.org/149828 16:07:18 so i have a question to raildo, eric, sajeesh 16:07:27 so how do you guys go about testing the changes 16:07:28 that has to be abandoned...I think so 16:07:58 I think that is the wrong approach 16:08:10 as I have commented on the patch 16:08:28 are you talking about https://review.openstack.org/151677  erissonsantos 16:08:37 vilobhmm, yes 16:09:00 yes sajeesh I think https://review.openstack.org/#/c/151677/13/nova/quota.py won;t fly 16:09:16 yes of course 16:09:27 what we need to do is keep the default values same and see if we have a sub-project and then reset the values to zero as mentioned in the spec IMHO 16:09:44 vilobhmm, you mean test the quota code? The last time that I had tested was running tox, since there is some bugs in the all patches, and I can't put this in a devstack or something like that. 16:09:45 please correct me if wrong 16:10:10 Vilobh, I have done like that in my new patch , https://review.openstack.org/#/c/149828/ 16:10:12 vilobhmm, yes, I do think so 16:10:32 raildo : thanks :) will come back to it in a while …. right now just focussing on https://review.openstack.org/151677 16:11:07 sajeesh even with https://review.openstack.org/#/c/149828/16/nova/db/sqlalchemy/api.py IMHO you need more 16:11:20 erickson , please check https://review.openstack.org/#/c/149828/. In that I have implemented the above said use case 16:11:23 vilobhmm, hum... I don't like this idea, since the current default values correspond to a single project, if we get this default values and divide to a hierarchy, you will have few resources for each subprojects 16:11:28 as in the quota_create query you will need to update the allocated field which will be part of nova.quotas 16:12:03 raildo, default values can be made higher 16:12:10 sajeesh : will check it out! Thanks for all the efforts ! 16:12:55 vilobh, it is not just api.py...more have been done 16:13:00 raildo, I think that approach is more safe 16:13:04 for now 16:13:07 sajeesh, the questions is, how much higher? I don't know how... I prefer just set to zero and the ops will decide this. 16:13:08 yes 16:13:14 ericsansantos : +1 16:13:36 raildo : you mean 0 even for the ROOT project ? 16:14:02 and then the respective admin does a nova quota-update to update the quota for the resp project ? 16:14:30 but this idea didn't go well when sajeesh tried to convince the same to nova folks….sajeesh is that true ? 16:14:37 sajeesh, i'll take a look at it 16:14:39 vilobhmm, yeap 16:14:41 yes 16:15:27 raildo, when there is no heirarchy the NestedQuotaDriver should exactly work like the DbQuotaDriver 16:15:46 sorry, I had a networking problem and dropped out 16:15:57 sajeesh, hum... 16:15:59 so do we have a conclusion on this that atleast for root project we let the default values be as it is whereas for sub-projects set it to 0 16:16:00 for that root projects should have default quota values 16:16:07 that is one reason 16:16:25 and then let the admin update the quota for resp sub projects 16:16:32 sajeesh : agree! 16:17:04 ok, can we agree on this then ? I can't see anything wrong with that 16:17:10 raildo: it will not be easy to merge this if you change current behaviour 16:17:14 the other one is that , the test cases of many other api s other than quota are written by expecting from finite default quota values 16:17:44 belmoreira ++ 16:17:46 true 16:17:56 belmoreira : +1 16:18:10 sajeesh's email to community explaining the same problem https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg53030.html 16:18:11 belmoreira:++1 16:18:24 belmoreira, I don't want to change the behaviour, I just think that the current default quotas are not enough to a hierarchy, but I'm ok with that, this is not a big problem 16:19:11 I agree that it does not look too nice to have to distinguish the root project from any other projects. On the other hand, it is already kind of a bit special, isn't it ? 16:19:13 values can be changed based on the scale of the organization 16:19:26 raildo : I agree the default are not enough but they can be changed IMHO using quota-update once the project is created 16:19:32 sajeesh : true 16:19:34 yes , it is 16:20:13 so if we agree on this nova, cinder can take the same route and we can keep the functionality unified 16:20:30 sounds good to me 16:20:31 vilob +1 16:20:32 vilobhmm, so, we can do the same on cinder 16:20:37 vilob: +1 16:20:55 I wonder if we need to update the BP for this 16:21:11 schwicke : the blueprint/spec already says that 16:21:17 ok 16:21:21 we shoudl be good here 16:21:46 #agreed: the root project should have default quota values and children set the default quota to zero 16:21:57 perfect ! 16:22:09 #agreed: we take the same approach for cinder and for nova 16:22:18 Let's move on then 16:22:27 ok 16:22:40 #topic: writing unit tests 16:22:55 where are we with this ? 16:23:01 Update : from cinder perspective I have not started it yet 16:23:08 ok 16:23:13 will need help here 16:23:20 to move the patch quickly ahead 16:23:27 vilobhmm: you mean the unit tests for cinder? 16:23:29 shwicke we have solve the issue with mocking keystone calls 16:23:34 ericsansantos has been very kind in providing help 16:23:50 yes, thanks erickson 16:23:56 schwicke : yes writing unit test for the nested quota driver changes 16:24:17 :) 16:24:22 sajeesh, how did you do that? 16:24:38 let'smake that an action item then 16:24:59 #action write unit tests for cinder 16:25:01 sorry...we have to solve the issue...I missed "to solve " :-) 16:25:17 yes, next on the list 16:25:29 what is the status of the unit tests for nova then ? 16:25:48 sajeesh, oh, I see 16:25:59 mocking keystone call is the road block 16:26:20 #topic mocking keystone call 16:26:23 I am planning to take advice from the community,by sending a mail 16:27:11 sajeesh: please do 16:27:14 sajeesh : is there any place in nova code where they have done it before that we can use as a reference i will check in cinder code 16:27:16 ok 16:27:17 About the keystone calls, why don't you check if the specified project is a subproject 16:27:28 i recommend take a look in the nova and cinder tests. I believe that exists tests when they need to mock a keystone client, to request something in Keystone 16:27:30 vilob, no.. 16:27:31 (make a keystone call in order to know if the project has a parent_id) 16:27:39 raildo : +1 16:27:47 on the controller level and provide this information to the configured quota driver? 16:28:13 raildo, they are mocking at the begining of the api call , not in the middle 16:28:24 sajeesh, we can do that too 16:28:39 we only need to change the approach, I guess 16:28:55 erickson, at controller won't it be having some other implications 16:29:11 sajeesh, can you explain? 16:29:33 I am also not sure of it 16:29:56 that was why I had thought of taking advice from nova core 16:30:05 I think if we make keystone calls at the controller level we can mock it on functional tests 16:30:31 ericksonsantos : If you can give some kind of a reference it should be useful IMHO 16:30:35 and we just have to pass to the configured quota driver what it needs to know (if the project is a subproject, for example) 16:30:42 yes 16:32:15 so do you agree on that? 16:32:20 I think it doesn't hurt asking in the mailing list. It also exposes the code for future review 16:32:37 belmoreira ++ 16:32:42 belmoreira +1 16:32:42 just to say that the other services don't access keystone directly, in other words, nova and cinder have to use the keystone client for that. 16:32:47 belmoreira: + 1 16:33:28 raildo: yes, that is my major concern 16:33:39 sajeesh: can you draft a mail to the mailing list then ? 16:33:52 yes ..surely 16:33:52 raildo : true…as part of https://review.openstack.org/#/c/149828/16/nova/api/openstack/compute/contrib/quotas.py I see that is already done… 16:34:28 sajeesh is using from keystoneclient.v3 import client 16:34:28 to use keystone client to access keystone from nova IMHO 16:35:13 and the approach should be same for unit test as well nova->keystoneclient->keystone 16:35:25 mocked may be 16:35:55 so we agree that sajeesh will send out an email …lets move to next topic 16:36:23 #agreed Sajeesh will contact the mailing list to get advice on the keystone call 16:36:46 one more thing ...only the test code is failing , otherwise code is working fine and all the use cases in the bp has been implemented 16:36:46 #action Sajeesh contact the mailing list to get advice on the keystone call 16:37:05 ok 16:37:29 sajeesh : awesome ! 16:37:30 I had "synchronisation of quota changes in sub-projects with Nova" on my original topic list 16:37:39 which is essentially the keystone calls we just discussed. 16:37:43 so let's move on 16:37:48 :-) 16:37:55 #topic code availability and merging of patches 16:38:16 sajeesh, so you've tested on devstack? 16:38:29 erickson ,yes 16:38:35 sajeesh, nice 16:38:51 cool 16:38:56 Can you please test it ? 16:39:06 sajeesh, sure 16:39:18 thanks 16:39:29 Update for Cinder 16:39:49 1. Seeing weird gate errors here https://review.openstack.org/#/c/185704/ otherwise this should get merged soon 16:39:52 #action ericksonsantos will test the code 16:39:58 have enough +1, +2 16:40:35 2. Will send out code for default quota values based on what we agreed on in today meeting i.e root gets default sub-project gets 0 16:40:58 ok 16:41:36 #action vilobhmm will update cinder code with agreed items from this meeting 16:41:55 Sajeesh has already uploaded the latest code, right ? 16:42:00 yes 16:42:01 3. I am on a family trip from Jun 24 - July 7th will work remotely as an when I get time…but I am commited to finshing my work on nested quota driver implementation.. 16:42:08 vilobhmm, migrate.exceptions.ScriptError: You can only have one Python script per version, but you have: /home/jenkins/workspace/gate-cinder-python27/cinder/db/sqlalchemy/migrate_repo/versions/047_add_allocated_in_quotas.py and /home/jenkins/workspace/gate-cinder-python27/cinder/db/sqlalchemy/migrate_repo/versions/047_add_per_volume_quota.py 16:42:23 vilobhmm, you need to do rebase on your patch 16:42:35 need to update the version of the table then 16:42:51 vilobhmm, yes 16:42:54 raildo : thanks for pointing that out….thats what happens when the reviews take longer :) 16:43:02 :) 16:43:15 want me to action item that / 16:43:16 ? 16:43:25 vilobhmm, I can help you with that if you want to 16:43:25 so if all all can chip in for the review when i post it in next 1 hour for https://review.openstack.org/#/c/185704/ that will be helpful 16:44:16 eriksonsantos : I will get it rolling in next hour…please review it if you can….thank you! 16:44:26 vilobhmm, ok 16:44:48 #action all: review next update of https://review.openstack.org/#/c/185704/ asap 16:44:51 schwicke : thats it from my side 16:44:58 ok 16:45:00 as in cinder nested quota driver 16:45:13 schwicke : thanks :) 16:45:47 schwicke: thanks a lot :-) 16:45:51 so I think we are through with that as well 16:46:07 and I will review all the patches that sajeesh will post so that we can move quicker.. 16:46:23 one thing is still not 100% clear to me: where are we with the unit test writing for the hierarchical quota in nova ? 16:46:28 vilobh thanks....I will review yours 16:47:00 sajeesh : thanks! 16:47:07 schwicke, we have to solve the keystone issue 16:47:15 ok, sure. 16:47:41 #topic AOB 16:47:43 then only we can proceed with the unit tests 16:48:14 schwicke : If we have covered all the topic I would like to have an open question for the team 16:48:15 so let's see what the community says. I also think we should review next Friday. 16:48:26 sure 16:48:32 yes 16:48:43 vilobhmm: please go ahead! 16:49:53 so sajeesh more specifically to you…since you tested the code on devstack….how dis you structure your policy.json and how did you make sure that the nova quota commands that you use ; make sue of the keystone v3 api ? 16:51:03 while testing the api calls , I use keystone v3 token token only 16:51:19 ok 16:51:31 but how did you structure your policy.json 16:51:36 and looking in the policy.json, you need a admin role 16:51:41 nova policy engine will take care of it 16:51:44 because for token scoping that changes needs to be there 16:51:52 https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L108 16:51:58 vilobhmm, ++ 16:52:21 I have changed the policy rules 16:52:39 I don't see a change for policy.json here…do they need to here https://review.openstack.org/#/c/149828/16 ? 16:52:44 raildo : sure 16:52:50 thanks for the link 16:53:17 vilob it is a different change 16:53:29 alrite then 16:53:38 that makes sense 16:53:45 you can traverse the dependancy chain and find it 16:54:20 sajeesh : if you can point me to that change it will be ncie 16:54:35 https://review.openstack.org/#/c/182522/ 16:54:51 cool 16:55:12 thats it from my side…thank you all…I think this meeting was really helpful ! 16:55:18 nice to meet you all ! :) 16:55:24 nice to meet you! 16:55:32 so let's meet again in a week from now! 16:55:44 see you next week :) 16:55:45 ok 16:55:50 let's try to gain some speed. The sooner we contact the comunity the better 16:55:55 ncie week end! 16:55:58 Good Bye all 16:56:01 see you 16:56:01 sure..you too ! 16:56:02 :) 16:56:06 #endmeeting