13:00:01 <alex_xu> #startmeeting nova api
13:00:02 <openstack> Meeting started Wed Jul 13 13:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:05 <openstack> The meeting name has been set to 'nova_api'
13:00:13 <alex_xu> who is here today?
13:00:50 <alex_xu> emm...only me?
13:00:55 <johnthetubaguy> o/
13:01:17 <alex_xu> johnthetubaguy: good afternoon :)
13:01:22 <johnthetubaguy> hello
13:01:31 <alex_xu> I guess we will have short meeting today
13:01:35 <gmann_> o/
13:02:07 <alex_xu> I didn't have too much for update today also
13:02:20 <alex_xu> I get some help for api-ref from the hackathon
13:02:41 <gmann_> alex_xu: great, i will start reviewing those tomorrow
13:02:46 <alex_xu> I probably need catch up some review for api-ref
13:02:49 <alex_xu> gmann_: thanks :)
13:03:09 <alex_xu> I also didn't see any update for policy discovery
13:03:13 <johnthetubaguy> yeah, I saw quite a few patches drop there
13:03:18 <edleafe> \o
13:03:30 * edleafe is partly here - on a phone meeting too
13:03:32 <johnthetubaguy> oh policy discovery? what were we expecting to see there again?
13:03:45 <alex_xu> #link https://review.openstack.org/322944
13:04:05 <alex_xu> #link https://review.openstack.org/335667
13:04:18 <alex_xu> both of them in WIP
13:05:02 <johnthetubaguy> ah, yeah
13:05:07 <johnthetubaguy> we need the second one
13:05:13 <johnthetubaguy> the first one would be good to have
13:05:21 <alex_xu> I guess those are last two
13:05:38 <alex_xu> johnthetubaguy: yea
13:06:00 <gmann_> i think the generation of policy file with default and override one
13:07:10 <alex_xu> for api deprecation, i didn't get time to work on yet. too much events in this month
13:07:38 <alex_xu> just back from hackathon, tomorrow will be Openstack China Days, then Mid-cycle...
13:07:50 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/deprecate-api-proxies
13:08:27 <alex_xu> there is propose from oomichi, about how to avoid merge all of patches together
13:08:29 <gmann_> alex_xu: what is pending on those, jenkin failure i think
13:09:10 <alex_xu> gmann_: I miss something for image links, and in quotas. Also need rebase, we just merged two API patches for FFE
13:09:26 <woodster_> o/
13:09:31 <gmann_> alex_xu: ohk, if you like i can update those.
13:09:33 <johnthetubaguy> I am curious if we should just squash those all together after we reviewed them, so they fit in one API microversion?
13:10:26 <alex_xu> gmann_: sure, i will appricate it
13:10:57 <alex_xu> johnthetubaguy: I think that way works
13:11:13 <gmann_> alex_xu: cool.
13:11:20 <johnthetubaguy> I mean, I like the small chunks to review, but we want that to land as one, I guess
13:11:21 <alex_xu> And after FFE, we have time to merge them
13:11:50 <alex_xu> johnthetubaguy: yeah, i see you
13:11:51 <gmann_> johnthetubaguy: you mean single patch after review all separate ?
13:12:01 <johnthetubaguy> yeah
13:12:03 <gmann_> johnthetubaguy: which will be easy and fast to review
13:12:05 <gmann_> ok
13:12:21 <gmann_> +1, nice idea
13:12:28 <johnthetubaguy> I mean we could do a feature branch, but I think that needs some work from infra to set it up
13:12:49 <gmann_> yea, more time consuming
13:13:56 <alex_xu> I think we probably can merge them after mid-cycle
13:14:46 <johnthetubaguy> or at the mid-cycle if its ready
13:14:59 <alex_xu> +1
13:15:26 <gmann_> ok, i will updates those before mid cycle so that you guys can review and merge there
13:15:45 <alex_xu> just saw edleafe's propose, about use 2.99 as placeholder, then correct the 2.99 in the last patch
13:15:50 <alex_xu> johnthetubaguy: do you like that way?
13:16:16 <johnthetubaguy> as long as we don't raise the max_version, that could work
13:16:32 <johnthetubaguy> i.e. its not actually a valid version
13:16:52 <alex_xu> yea, I didn't found any problem for that way for now
13:16:56 <johnthetubaguy> tempted to use 2.999, given 2.99 doesn't feel that far away
13:17:34 <alex_xu> so let us go that way?
13:17:43 <edleafe> johnthetubaguy: 2.999999999 ?
13:17:50 <alex_xu> :)
13:17:50 <edleafe> :)
13:17:51 <gmann_> :)
13:18:00 <johnthetubaguy> edleafe: sure :)
13:18:16 <gmann_> we are at  2.34 only i guess
13:18:31 <edleafe> gmann_: 2.35 as of yesterday
13:18:42 <gmann_> ok.
13:18:56 <johnthetubaguy> as long as no user can ever trigger it, we should be fine
13:19:08 <alex_xu> yea
13:19:48 <alex_xu> so we are cool?
13:19:54 <johnthetubaguy> I think we error out if you request something higher the max_version, so that protects us
13:19:55 <edleafe> maybe need a gate check?
13:20:09 <edleafe> Or will max_version do it?
13:20:25 <alex_xu> johnthetubaguy: yes, we error out if you request higher than max_version for now
13:20:26 <gmann_> johnthetubaguy: yea
13:20:34 <edleafe> so we don't accidentally merge 2.999
13:20:47 <johnthetubaguy> unit test check would do no harm
13:20:54 <edleafe> alex_xu: will that cause every patch to fail Jenkins then
13:21:11 <edleafe> it's hard to get reviews with all that red on the patch
13:21:41 <alex_xu> edleafe: emm...I guess unittest will be go
13:21:53 <alex_xu> but it's worth to update one patch as that way, and to see what happened
13:21:56 <gmann_> i think  it will fail and would not be able to merge
13:22:17 <gmann_> I tried on imgae_ref UUID and got failure
13:22:44 <gmann_> #link https://review.openstack.org/#/c/338802/
13:23:00 <edleafe> I used 2.99 on https://review.openstack.org/#/c/327809/, but also updated max_version
13:23:09 <gmann_> had to update max_version - https://review.openstack.org/#/c/338802/1/nova/api/openstack/api_version_request.py
13:23:17 <johnthetubaguy> we can't change max_version, thats user visible
13:23:28 <gmann_> yes,
13:23:35 <edleafe> johnthetubaguy: as a placeholder strategy
13:23:42 <gmann_> and without max_version change we can not merge patch
13:23:53 <edleafe> johnthetubaguy: that's why I thought a gate check would be better
13:24:22 <gmann_> edleafe: it will be a user interface then instead of place holder i think
13:24:27 <alex_xu> gmann_: if the unitest only call the controller obj direclty, i remember there isn't a check for max_version
13:24:57 <alex_xu> so we will fine for unittest
13:25:17 <johnthetubaguy> so the functional tests are failing on the patch, I guess it found why you can't increase max_version
13:25:48 <gmann_> alex_xu: but schema version needs microversion in request for calling controller method also
13:26:30 <johnthetubaguy> gmann_: can't they all point at a constant that is 2.999?
13:27:17 <alex_xu> gmann_: there is max_version checks for schema version?
13:28:15 <gmann_> johnthetubaguy: alex_xu humm, i think while wrapping the controller method it needed but max_version check i need to see
13:28:29 <gmann_> i forgot where exactly it was causing the issue
13:28:40 <alex_xu> gmann_: actually the currently patches also update max_version in the last one
13:28:40 <johnthetubaguy> I am OK introducing a new PARTIAL_API_VERSION=2.999 or something like that?
13:29:31 <gmann_> alex_xu: yea.
13:30:02 <gmann_> johnthetubaguy: may be we are making it more complicated with that
13:30:17 <alex_xu> yea, i'm ok also. I added constant MAX_PROXY_API_SUPPORT_VERSION in https://review.openstack.org/#/c/338802/1/nova/api/openstack/api_version_request.py, we just need change it to 2.999
13:30:31 <johnthetubaguy> alex_xu: thats the one I was thinking about
13:30:40 <alex_xu> johnthetubaguy: yea
13:30:41 <gmann_> or we can just review all those separately and merge and rebase if any version bump in between
13:30:45 <edleafe> johnthetubaguy: how about 9.99? No way we'll ever hit that :)
13:31:00 <johnthetubaguy> edleafe: maybe
13:32:29 <alex_xu> gmann_: i think 2.999 way isn't very hard
13:32:47 <alex_xu> whatever we need rebase, and just need to change the 2.999 :)
13:33:30 <gmann_> alex_xu: ok. with  MAX_PROXY_API_SUPPORT_VERSION?
13:33:31 <johnthetubaguy> the key thing is, don't expose this to the user, even if they request that specific version
13:33:42 <alex_xu> gmann_: yeah
13:34:04 <gmann_> yea, m ok that way
13:34:19 <alex_xu> cool :)
13:34:27 <alex_xu> johnthetubaguy: yea
13:34:54 <alex_xu> I think that is all i have, anything more we want to bring up?
13:35:27 <alex_xu> #link https://review.openstack.org/340629
13:35:31 <alex_xu> gmann_: this one ^ ?
13:35:33 <gmann_> alex_xu: if you can check this - https://review.openstack.org/#/c/340629/
13:35:40 <gmann_> alex_xu: :) yea
13:35:41 <alex_xu> gmann_: yea :)
13:35:57 <gmann_> johnthetubaguy: that is actually in Newton only so we do not need backort
13:36:27 <johnthetubaguy> gmann_: good point, I forgot
13:36:45 <alex_xu> we just miss that one check in the tests, then we didn't catch that mistake :(
13:37:24 <johnthetubaguy> yeah, I was a bit worried about that
13:37:30 <gmann_> alex_xu: yea, that was caught on schema validation check in tempest
13:38:46 <gmann_> alex_xu: johnthetubaguy can we add hacking check for those at least returning of such HTTP success? but not sure how easy and correct that will be
13:39:00 <alex_xu> yea, maybe worth to check, whether we have other place to use that way to return response
13:39:14 <alex_xu> gmann_: that will be great if can
13:39:24 <gmann_> alex_xu: cool, i will check that
13:39:48 <alex_xu> gmann_: or we didn't allow return response obj, only allow None or dict?
13:40:16 <alex_xu> that can be done at our wsgi code
13:41:16 <gmann_> alex_xu: yea but for multiple return like that API
13:41:55 <alex_xu> gmann_: ah, good point
13:43:03 <alex_xu> let's to find a better way to avoid that
13:43:22 <gmann_> alex_xu: sure
13:43:34 * alex_xu adds a todo to think about that
13:43:52 <alex_xu> ok, anything more we want to bring up?
13:45:04 <gmann_> nothing from my side
13:45:25 <alex_xu> ok, let's end the meeting early
13:45:36 <edleafe> thanks alex_xu
13:45:39 <alex_xu> thanks all!
13:45:45 <gmann_> Thanks.
13:45:52 <alex_xu> #endmeeting