16:02:25 <schwicke> #startmeeting hierarchical_multitenancy
16:02:26 <openstack> Meeting started Fri Jul  3 16:02:25 2015 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:29 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:02:45 <schwicke> who's there today ?
16:02:51 <rodrigods> o/
16:02:56 <sajeesh> o/
16:03:01 <abrito_> o/
16:03:35 <schwicke> #topic review of action items
16:04:33 <schwicke> we had:  erickdonsantos will take over from vilobhmm while he's on vacation
16:04:56 <rodrigods> schwicke, he is currently working on it
16:05:11 <schwicke> ok
16:05:15 <rodrigods> he has already fixed the tests, but have found some bugs and he is currently fixing them
16:05:23 <sajeesh> ok
16:06:00 <rodrigods> the major issue was that the code wasn't considering the data from the db for a subproject
16:06:10 <rodrigods> it was always returning 0, not checking the DB first
16:06:11 <ericksonsantos> hi \o
16:06:31 <sajeesh> hi erickson
16:06:32 <schwicke> Hi
16:06:36 <schwicke> welcome!
16:06:47 <schwicke> we've just started to review the action items
16:06:49 <ericksonsantos> thanks
16:07:57 <ericksonsantos> nice, I'm working on cinder code. For now, I have just to implement some tests
16:08:03 <ericksonsantos> and upload a new patch
16:08:25 <sajeesh> ok
16:08:43 <schwicke> ok
16:08:57 <schwicke> do you have a time estimate ?
16:09:32 <ericksonsantos> monday I guess
16:09:37 <schwicke> great!
16:09:54 <sajeesh> good !
16:10:35 <schwicke> this is for  https://review.openstack.org/#/c/194406/ ?
16:11:11 <ericksonsantos> schwicke, yes
16:11:15 <schwicke> then we had:  sajeesh will ask for feedback on failing tests for
16:11:15 <schwicke> https://review.openstack.org/#/c/182140/ and sajeesh will contact core developers on IRC in #openstack-nova
16:11:20 <schwicke> (moving on)
16:11:35 <schwicke> sajeesh: did you succeed with that ?
16:11:43 <sajeesh> yes I had contacted them
16:11:55 <sajeesh> I will start fixing it
16:12:14 <rodrigods> can you give more details?
16:12:29 <ericksonsantos> what were their suggestions?
16:13:07 <sajeesh> rodrigo, dims had asked me to fix it first and then he will see
16:13:18 <rodrigods> fix it how?
16:13:28 <rodrigods> the wsgi.py check, right?
16:13:28 <sajeesh> I am planning to change the test case
16:13:36 <rodrigods> the tempest test?
16:13:39 <sajeesh> yes wsgi.py
16:13:41 <sajeesh> yes
16:14:40 <schwicke> what's the test case then ?
16:15:06 <sajeesh> I have to see it.
16:15:24 <rodrigods> sajeesh, I've an email to you with the testcase
16:15:27 <rodrigods> and why it is failing
16:15:37 <rodrigods> I believe I've sent it before the meeting last week
16:15:40 <sajeesh> yes I have seen it
16:16:02 <rodrigods> I'm not sure whether is the right direction to fix the tempest test
16:16:02 <sajeesh> based on that only, I am planning to solve
16:16:22 <rodrigods> since the action is intended to fail
16:16:40 <sajeesh> let us fix it that way first
16:16:54 <rodrigods> so the checks you've removed from wsgi.py is causing this check to not happen
16:17:03 <rodrigods> anyway...
16:17:18 <sajeesh> I think so...I haven't gone deep into it
16:18:21 <rodrigods> so consider to fix the Nova code, instead of going to change a behavior from a tempest test
16:18:22 <sajeesh> I will check it
16:18:34 <ericksonsantos> rodrigods ++
16:18:44 <rodrigods> you may need to readd the checks you've removed in the API that is failing
16:18:50 <schwicke> yes, sounds more reasonable to me as well
16:19:00 <sajeesh> rodrigo, surely I will consider all options
16:19:39 <schwicke> sajeesh: do you need any help with that ?
16:20:01 <sajeesh> any help is welcome
16:20:04 <sajeesh> :-)
16:20:42 <schwicke> maybe somebody can help out with a patch ?
16:21:03 <ericksonsantos> once, /
16:21:13 <vilobhmm> schwicke : sorry to interupt
16:21:14 <vilobhmm> ericksonsantos, all : I have a flight to catch but ericksonsantos if you can submit a patch with the feedback that you and sajeesh had mentioned, so by the time I am back we can move ahead with this one….once I am back I can take it ahead…
16:21:32 <ericksonsantos> once I've finished with cinder code, I can take a look. *
16:21:34 <vilobhmm> talking specifically about https://review.openstack.org/#/c/194406/
16:21:43 <vilobhmm> ericksonsantos : ^^
16:21:46 <sajeesh> actually I have to see , if that  test becomes redundant when I remove the context checking from wsgi.py
16:22:24 <ericksonsantos> vilobhmm, nice, I'll do it :)
16:22:52 <sajeesh> if it becomes redundant , it makes sense to remove it
16:23:14 <rodrigods> sajeesh, why is it redudant ?
16:23:15 <vilobhmm> ericksonsantos : thanks
16:23:42 <rodrigods> it checks if a user can create a keypair in a project he isn't authorized to
16:23:45 <sajeesh> I am not sure that it is redundant...I mean if it is redundant
16:24:36 <schwicke> is there another test doing the same thing, or what makes it redundant /
16:24:37 <schwicke> ?
16:25:11 <sajeesh> schwicke...that I have to check
16:25:17 <rodrigods> what is broken is the behavior, not the test
16:25:23 <rodrigods> if we have 2 tests doing the same thing
16:25:25 <rodrigods> both should fail
16:25:38 <sajeesh> ok
16:25:51 <schwicke> +1
16:27:07 <schwicke> so what is the conclusion?
16:27:40 <sajeesh> can't say right now
16:28:13 <rodrigods> IMHO a authorization check was removed, a specific API is failing (associate a keypair to an instance in a project) so this API needs this check
16:28:27 <ericksonsantos> sajeesh, I have to think if makes sense remove that checking in wsgy.py
16:29:00 <rodrigods> an option is to readd this same check in the specific API
16:29:04 <rodrigods> since it seems to need it
16:29:04 <sajeesh> according to the bp, token should be scoped to parent for update and delete
16:29:59 <sajeesh> that is already...there and I can shift the test to that area
16:30:46 <rodrigods> which area? all calls go through wsgi.py and than to the specific API
16:30:59 <rodrigods> if the test is faling it means that neither have the check
16:31:15 <rodrigods> speaking logically (haven't looked the code)
16:31:32 <sajeesh> context checking is done api
16:31:42 <sajeesh> done inside api call
16:32:16 <sajeesh> conext checking is done inside the api call
16:32:40 <sajeesh> if I can shift this test to that area , I think it can be solved
16:34:28 <schwicke> shall we try it the way sajeesh suggests ?
16:35:28 <abrito_> sajeesh, ericksonsantos, schwicke: can't we parallelize a bit more? Maybe have some fresh eyes looking at this one patch for a while and start another one in the chain?
16:35:58 <schwicke> abrito: +1
16:36:04 <sajeesh> +1
16:36:52 <schwicke> let's move on for now on the action item review
16:37:35 <schwicke> sajeesh will work on implementing monkey patching the keystone calls
16:37:47 <sajeesh> yes.. I am doing that
16:37:47 <schwicke> sajeesh: did you make any progress on this one ?
16:38:01 <schwicke> can you give a time estime when this will be finished
16:38:11 <sajeesh> schwicke...progress is there .
16:38:31 <abrito_> just talked to Raildom, he could help with this one patch.
16:38:57 <sajeesh> I can say that I can complete this in a few days....
16:38:58 <abrito_> meanwhile Ericksonsantos could help in the cinder front.
16:39:25 <schwicke> sounds good
16:39:31 <sajeesh> thanks raildo  !!!!
16:40:59 <rodrigods> can you trigger the action schwicke ?
16:41:05 <schwicke> sure
16:41:11 <rodrigods> raildo will take a look in the patch and will fix it
16:41:27 <rodrigods> #link https://review.openstack.org/#/c/182140/
16:41:43 <schwicke> #action raildo will take a look in the patch and will fix it #link https://review.openstack.org/#/c/182140/
16:41:49 <schwicke> thanks for the link!
16:42:45 <schwicke> what else is pending ? I saw a discussion about weather or not a different driver should be used or if the existing one should be extended
16:43:01 <rodrigods> my opinion is the old one from sajeesh
16:43:19 <sajeesh> ?
16:43:22 <rodrigods> since the NestedQuotaDriver works as the QuotaDriver when HMT is not considered
16:43:42 <rodrigods> I don't see a reason why we would want to replicate code
16:43:49 <rodrigods> or behavior
16:43:52 <ericksonsantos> rodrigods +1
16:44:57 <schwicke> the main argument for having two different drivers is the transition from the old to the new one
16:45:01 <sajeesh> rodrigo...there won't be code duplication NestedQuotaDriver inherits from DbQuotaDriver
16:45:18 <sajeesh> It is mainly done to make transition safer and smoother
16:46:10 <sajeesh> I mean if it inherits
16:46:20 <ericksonsantos> we can make this change without having to create a new driver, the behavior will still be the same
16:46:21 <abrito_> originally I was in favor of having two drivers
16:46:30 <abrito_> but then I understood that in a conversation with Morgan
16:46:37 <sajeesh> we can do....
16:46:43 <abrito_> it was suggested that a single should be a smoother experience
16:46:58 <abrito_> did I miss something Sajeesh?
16:47:31 <sajeesh> abrito...then everybody will be afraid of potential risks
16:47:55 <schwicke> putting my sysadmin head on I'd feel better if I could upgrade to the new version of nova without changing the driver, and then having the possiblity to switch on and test the new thing
16:48:36 <schwicke> in particular for large installations - which are exactly those who may be interested in the new features
16:48:36 <sajeesh> so in nova we are proposing it as an optional driver in the intial release and default in the successive one
16:49:26 <sajeesh> shwicke ...issue is not with the user acceptance...issue is with the code acceptance
16:49:37 <schwicke> while I agree that from a pure design point of view a single driver solution looks more clean, I really believe that from a sysadmins point of view having an independent driver is more save
16:50:26 <abrito_> ok, but then there are two reasons
16:50:45 <abrito_> the sysadmins could be more confortable
16:51:15 <abrito_> and the cores would be less afraid of having such an important code buggy
16:51:21 <schwicke> sajeesh: from the design the two driver solution is indeed a bit more ugly even if you inherit the old code. It implies that you will have to iterate on the code later to get rid of the old driver
16:51:34 <sajeesh> ++1 brito
16:51:40 <abrito_> do we then agree on this one?
16:51:56 <schwicke> abrito: +1
16:52:00 <schwicke> that's the point
16:52:01 <sajeesh> not much iteration is required
16:52:32 <schwicke> so we agree that it is better to have 2 drivers, correct ?
16:52:40 <rodrigods> ok, let's create an optional driver
16:53:23 <schwicke> #agreed we create an optional driver to ease the migration. This should be the case both for cinder and nova.
16:53:33 <ericksonsantos> so, ok
16:53:53 <schwicke> That's quite an important outcome of this meeting :)
16:54:00 <sajeesh> yes :-)
16:54:12 <schwicke> we are running out of time.
16:55:33 <schwicke> I think we should try to make use of the skype block during the week
16:55:40 <schwicke> #topic AOB
16:55:52 <sajeesh> yes
16:56:09 <schwicke> specifically now to get the tests going. We need more discussion on this it seems
16:56:18 <schwicke> Do we agree ?
16:56:44 <sajeesh> yes
16:57:09 <schwicke> do we have raildo in the group chat  ?
16:57:30 <abrito_> so everyone is already on the skype group
16:57:42 <abrito_> schwicke: yes, he is
16:57:56 <schwicke> excellent!
16:58:43 <schwicke> #agreed use skype chat during the week to coordinate
16:58:47 <schwicke> Time is out
16:58:54 <rodrigods> thanks guys
16:58:56 <schwicke> let's meet again next Friday to review
16:59:00 <rodrigods> ++
16:59:05 <ericksonsantos> thank you all!
16:59:07 <schwicke> to speed up things
16:59:10 <schwicke> #endmeeting