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