12:08:07 #startmeeting nova-api 12:08:08 Meeting started Tue Feb 9 12:08:07 2016 UTC and is due to finish in 60 minutes. The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:08:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:08:11 The meeting name has been set to 'nova_api' 12:08:52 o/ 12:09:25 so it's a holiday in china so probably a short meeting today 12:09:27 agenda - https://wiki.openstack.org/wiki/Meetings/NovaAPI 12:09:33 sdague: yea 12:10:02 ok 12:10:09 there are no open actions I can see from last meeting 12:10:43 I'm going to just jump us to open discussion 12:10:47 #topic Open Discussion 12:10:59 what are the burning issues that people have at the moment 12:11:06 sdague: yea. 12:11:11 https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/scheduler_hints.py#L34-L37 is on the list 12:11:40 sdague: yea 12:11:43 gmann_: which I think is your question 12:12:01 sdague: not this actually. this bug - https://bugs.launchpad.net/nova/+bug/1539351 12:12:03 Launchpad bug 1539351 in OpenStack Compute (nova) "Authorization by user_id does not work in V2.1 API" [Undecided,In progress] - Assigned to jichenjc (jichenjc) 12:12:26 sdague: oh yea for sch hint a spec we expected. 12:12:53 as per jichen that bug might be in all actions? 12:13:11 yes, most actions , I think , at least from my test result 12:13:32 ok on the auth by user_id bug - https://bugs.launchpad.net/nova/+bug/1539351 - I wonder what the keystone folks feel about that 12:13:34 Launchpad bug 1539351 in OpenStack Compute (nova) "Authorization by user_id does not work in V2.1 API" [Undecided,In progress] - Assigned to jichenjc (jichenjc) 12:13:52 because as mtreinish said during a tempest thread on this, blocking by user_id is pretty unexpected 12:14:28 sdague: yea just read that mail. 12:14:34 perhaps we should have the bigger conversation around that 12:14:44 in the mail list? 12:14:53 so the only thing this triggered for me was key_pair were we do restrict by user_id 12:15:05 sdague: yea i also feel so, tenant isolation was ok but with user id still needs to think more 12:15:23 jichen: yeh 12:15:25 johnthetubaguy: yea with 2.10, we manage with user-id 12:15:55 johnthetubaguy: keypair makes some sense there 12:16:08 yeh, I don't know 12:16:12 yeah, I think keypair defaults to per_user, as I understand it 12:16:16 right 12:16:19 its the one odd bit 12:16:27 I don't like the idea of us supporting the other things 12:16:43 johnthetubaguy: ok, perhaps then respond on the nova bug ML thread with that 12:16:51 I'm kind of fine saying that's not supported 12:16:57 although if we had hierarchical tenancy working better, I would feel better about blocking that 12:17:41 yeah, I should give that some thought and respond 12:18:10 ok, so lets assume we aren't going to support it 12:18:27 yeah, its a spec, etc, if thats wanted anyways 12:18:38 #info we do not intend to support arbitrary user_id permission in the API any more 12:18:43 sdague: johnthetubaguy +1 12:18:51 #action johnthetubaguy to respond on mailing list 12:19:02 ok, other open discussion topics? 12:19:10 ok 12:19:23 I have one about tempest / microverion testing for Nova as there is some overlap here 12:20:20 sdague: ok 12:20:31 ok, lets talk about Tempest testing for Nova microversions 12:20:56 when we landed 2.20 we really wanted some testing of it for real, it impacts volumes & shelved instances 12:21:17 I thought the tempest infrastructure was there, but it's really not 12:21:29 gmann_: are you working on that infrastructure? or do you know who is? 12:21:50 sdague: yea, i am done with infrastructure. 12:21:51 because I had an idea of a simpler way to deal with it instead of all the passing through layers 12:21:56 gmann_: ok, it doesn't work 12:22:05 sdague: all patches are merged and v2.2 are on gate 12:22:13 it really doesn't work 12:22:23 sdague: oh, i did not get 12:22:26 I don't know how v2.2 is working 12:22:39 because I definitely could never get a header sent in 2.20 12:22:51 anyway 12:22:59 sdague: you mean for v2.20? 12:23:02 yes 12:23:09 sdague: yea that is not yet supported 12:23:20 gmann_: I don't know what that means 12:23:31 sdague: sorry, i missed. all compute service clients are not in suport yet 12:23:36 sdague: due to tempest-lib 12:23:51 sdague: only keypair client is supprted for microversion 12:23:53 ok, so it seems like this is more complicated than it should be 12:24:19 because the assumption is that software will be written so that nova microversion is a hard coded constant in it 12:24:25 sdague: but for making all compute service client working for microversion, i just need to migrate framework in lib 12:24:37 sdague: and change the base class for all service cleints 12:24:41 so, tempest_lib should just have COMPUTE_MICROVERSION 12:24:44 sdague: just 3 patch 12:24:51 and have a fixture in tempest that sets it 12:25:03 instead of instrumenting every single tempest-lib client 12:25:17 sdague: ok, that i can change, currently its is had coded in base compute client 12:25:30 gmann_: right, and there is all that work to pass things through 12:25:41 that just seems like a lot of effort 12:25:48 and will have to be set everywhere 12:26:10 sdague: yea but still we need to add microversion in header on lib side 12:26:13 because if we need a tempest_lib release to test a new microverion, that's a failure of the system 12:26:34 gmann_: right, but we'll do that at the def request level 12:26:58 sdague: like https://github.com/openstack/tempest/blob/master/tempest/services/base_microversion_client.py#L47 12:27:05 sdague: yea 12:27:15 at request level not in al client 12:27:33 right, but api_microversion should not be an instance variable 12:27:38 it should be a global 12:27:46 and change it with a fixture if you want to 12:27:51 sdague: but as long as service client are in lib we still need to change them due to new API param etc 12:28:10 if it's a new parameter 12:28:16 it's not always 12:28:24 sdague: yea not always 12:28:45 sdague: as we are thinking to move lib interfaces to tempest, that would be fine 12:28:53 sure 12:29:21 anyway, the amount of work to support new microversions in tempest right now is far too high, we need to figure out how to do this better otherwise no one is going to test these 12:29:38 sdague: that microversion variable only changed by tempest from tests case selection 12:29:50 sdague: humm 12:30:11 ok, let's take this over to #qa after this meeting 12:30:17 sdague: adding for v2.10 too - https://review.openstack.org/#/c/277763/ 12:30:19 sdague: sure. 12:30:27 ok, any other topics? 12:31:05 ok, we'll call it a meeting. Thanks folks 12:31:11 #endmeeting