12:00:10 <alex_xu> #startmeeting nova api
12:00:11 <openstack> Meeting started Tue Mar  1 12:00:10 2016 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:14 <openstack> The meeting name has been set to 'nova_api'
12:00:15 <alex_xu> who is here today?
12:00:18 <gmann_> hi
12:00:48 <sdague> o/
12:01:08 <alex_xu> today is quite
12:01:29 <alex_xu> #topic API futures - patches for approved specs
12:01:40 <jichen> o/
12:01:57 <alex_xu> we finish the goal we merge the LM patches \o/
12:02:06 <alex_xu> last week
12:02:27 <alex_xu> anything people want to bring up today?
12:03:20 <alex_xu> sdague: we will freeze the client in Thursday also?
12:03:47 <sdague> alex_xu: yes, I think so, so probably we should get people to prioritize looking at the microversion lands in the clients
12:04:08 <sdague> so that we can actually have users have these features on the command line
12:04:38 <alex_xu> yea, those LM API client patch didn't merge yet
12:05:00 <alex_xu> #link https://review.openstack.org/281335
12:05:04 <alex_xu> there is the first one
12:05:17 <alex_xu> #link https://review.openstack.org/#/c/260383/
12:05:19 <alex_xu> there is the last one
12:06:05 <alex_xu> then we won't have any more api patch landing in Mitaka
12:06:21 <sdague> right, I'm pretty sure we're done on API patches for Mitaka
12:07:07 <alex_xu> sdague: https://review.openstack.org/281143 I changed this to the way you like, but I think it isn't hurry, it still can be merged after freeze
12:07:52 <eliqiao> o/
12:07:56 <alex_xu> I guess no more question, then let's move on
12:07:58 <Kevin_Zheng> Sorry to be late, internet connection very bad today in our office
12:08:01 <sdague> alex_xu: right, that patch looks good
12:08:08 <sdague> alex_xu: thanks for handling that
12:08:09 <gmann_> sdague: how about https://review.openstack.org/#/c/248662/
12:08:13 <alex_xu> sdague: np
12:08:30 <gmann_> sdague: as we are deprecating hook but still we should fix this issue?
12:08:40 <sdague> gmann_: let's come back to that in open discussion
12:08:42 <gmann_> sdague: or not so critical
12:08:48 <gmann_> sdague: sure
12:09:05 <alex_xu> #topic Nova Microversion testing in Tempest
12:09:18 <alex_xu> gmann_: sdague your turn
12:09:32 <sdague> I believe we landed the change that gmann_ posted for that
12:09:38 <gmann_> sdague: yea
12:09:45 <sdague> gmann_: where do we stand now?
12:10:01 <gmann_> sdague: alex_xu i have posted other 2 patches to migrate to /lib and support microversion in all clients
12:10:07 <cdent> o/ sorry I'm late
12:10:17 <gmann_> sdague: https://review.openstack.org/#/c/284387/ https://review.openstack.org/#/c/284414/
12:10:34 <gmann_> sdague: after those we can implement any microversion tests
12:10:40 <gmann_> sdague: if you can have look into those
12:11:07 <sdague> gmann_: sounds good
12:12:04 <gmann_> sdague: do you link for v2.20 tests patch
12:12:11 <gmann_> sdague: i can update that if you like
12:12:28 <sdague> gmann_: oh, right, that would be great
12:13:43 <alex_xu> sounds we are good at here, so let us move on?
12:14:04 <gmann_> alex_xu: yea.
12:14:11 <alex_xu> #topic open
12:14:32 <alex_xu> #link https://review.openstack.org/#/c/248662/
12:14:38 <alex_xu> gmann_: sdague ^ we can back to this
12:15:00 <sdague> right, so there is a mailing list thread about nova.hooks now
12:15:15 <sdague> basically, I think we should either be testing this or deprecate it
12:15:27 <sdague> if the deprecation patch lands, then I'm happy taking the fix without functional testing
12:15:35 <gmann_> sdague: +1 for deprecate
12:15:48 <sdague> because spending a bunch of time functional testing a features we're going to remove in the near future is busy work
12:16:11 <gmann_> humm, right
12:16:20 <alex_xu> yes
12:17:11 <alex_xu> it is a medium prority bug, so sounds ok, not critical for something
12:17:26 <alex_xu> at least not critical for this point
12:17:48 <gmann_> yea
12:17:49 <sdague> gmann_: I updated my review comment
12:18:40 <gmann_> sdague: i see. Thanks
12:19:03 <sdague> so there were a couple of other interesting API bits that cropped up
12:19:25 <sdague> have people noticed the regression tests in tree?
12:20:02 <jichen> yeah
12:20:03 <alex_xu> sdague: no, do you have link?
12:20:04 <sdague> https://github.com/openstack/nova/blob/10da208f02fee532171d1d9e4667d0b71c455b8a/nova/tests/functional/regressions/README.rst#L13
12:20:36 <sdague> I started building a little mini framework for building a functional test for a bug to verify behavior before a fix, and after
12:21:01 <sdague> it is most applicable to API bugs
12:21:21 <sdague> or, anythign you don't need actual libvirt for
12:21:34 <sdague> https://github.com/openstack/nova/blob/10da208f02fee532171d1d9e4667d0b71c455b8a/nova/tests/functional/regressions/test_bug_1522536.py
12:21:39 <gmann_> sdague: oh, that's very nice
12:22:14 <sdague> anyway, I found it easier to think about some of the api bugs by actually building the reproduce in tree, then fixing the code for them
12:22:21 <alex_xu> sdague: is there clear rule which kind of bug need add that regssion test?
12:22:27 <gmann_> sdague: it is written that, those can removed later if needed but should not we keep those as normal tests?
12:22:43 <sdague> gmann_: honestly, I figured we'd keep them unless they got in the way
12:23:11 <sdague> alex_xu: I think any bug is fine. We're not going to make this a requirement of any bug
12:23:22 <sdague> but if you want to do that, it's a good way to go
12:23:29 <gmann_> sdague: and keep moving those to functional tests if suitable?
12:23:45 <sdague> gmann_: I don't know, I think I'm fine if they are just in this directory
12:23:58 <gmann_> ok
12:24:10 <sdague> this is not about covering every possible edge case, it's about covering issues that come up often enough that people bothered to report bugs on them
12:24:18 <gmann_> sdague: those will run as functional tests gate job right
12:24:22 <sdague> gmann_: yes
12:24:30 <gmann_> ok
12:25:08 <sdague> alex_xu: I'm actually surprised your patch is passing this - https://github.com/openstack/nova/blob/10da208f02fee532171d1d9e4667d0b71c455b8a/nova/tests/functional/regressions/test_bug_1541691.py
12:25:16 <sdague> we should figure out what's happening there
12:25:44 <alex_xu> sdague: emm...that is interesting, I will take a look it
12:25:55 <sdague> we should just look at the test run in detail after the meeting
12:26:09 <alex_xu> sdague: ok, cool
12:26:12 <sdague> the other thing of note is the case sensitivity issues on metadata
12:26:48 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-February/087404.html
12:27:04 <sdague> I think we've resolved that metadata keys are just going to be non case sensitive
12:27:09 <sdague> because of mysql
12:27:21 <sdague> but that means some python code to deal with it
12:27:22 <cdent> it is just keys that's the issue, not values?
12:27:28 <sdague> just keys
12:27:36 <cdent> then yeah, that seems reasonable
12:27:46 <sdague> because of the way that lookups / deletes are processed
12:28:48 <sdague> that has some api implications, and I guess the real question is should we be enforcing lower case in the jsonschema for these
12:29:01 <sdague> because the current behavior is all wonky
12:29:57 <sdague> although, I think, largely synthetic. They look like the kind of bugs a qa team finds when they are poking at the world. I haven't seen a bug that looks like an actual field issue yet.
12:30:23 <sdague> anyway, those were my API related things
12:30:31 <alex_xu> yes, I didn't think any people depend on that also
12:30:40 <gmann_> humm, yea
12:30:54 <alex_xu> it is ok for enforcing lower case in the jsonschema
12:31:20 <sdague> right, I don't know how much people might be setting upper case things today
12:31:29 <gmann_> but will that be ok for DB support case sensitive keys?
12:31:41 <sdague> gmann_: it won't break there
12:31:51 * gmann_ still need to read full mail
12:32:08 <gmann_> sdague: but json schema will block upper case right
12:32:13 <sdague> oh, right, so the issue is if we are going to fully enforce at json schema, then we'll also probably need a data migration to force all the keys to lower in the db
12:32:19 <sdague> gmann_: right
12:32:42 <johnthetubaguy> alex_xu: sdague: just to confirm on python-novaclient, we have to make the final release for Mitaka sometime before the end of Thursday, as I understand it
12:32:45 <sdague> I think something like that probably needs an ops email, just to figure out if anyone is using upper case
12:32:51 <sdague> johnthetubaguy: yep
12:32:56 <alex_xu> johnthetubaguy: thanks, got it
12:32:57 <gmann_> sdague: yea
12:33:16 <johnthetubaguy> not sure an Ops email helps though, isn't this an end user facing API?
12:33:26 <alex_xu> sdague: is it ok just using a python code to convert the data from the db, then needn't data migration?
12:33:28 <sdague> johnthetubaguy: and I think any API team focus should be on landing microversions in the client to support these new LM features
12:33:38 <johnthetubaguy> sdague: +1
12:33:40 <sdague> johnthetubaguy: well, the first one is aggregate metadata
12:33:46 <sdague> that's not user facing
12:33:54 <johnthetubaguy> ah, OK, true, I was thinking about server metadata
12:33:59 <sdague> server metadata is also an issue
12:34:06 <sdague> and... I agree, that's more complicated
12:34:29 <johnthetubaguy> I was thinking we should fix server metadata, and make the others match
12:34:49 <sdague> ok, well aggregate metadata was the one we were working on first
12:35:15 <sdague> mostly because if we get push back on the fix once people deploy it, it's easier to unwind
12:35:41 <johnthetubaguy> ah, yeah, thats true
12:35:57 <johnthetubaguy> any mess up there, is less impacting
12:37:35 * eliqiao is still on line ?
12:37:49 <sdague> johnthetubaguy: now that you are back up, the nova.hooks deprecation patch is updated
12:38:19 <sdague> I also looked through the thread, and am skeptical about the usefulness of taking this to the ops list, because I have no idea what we'd do with the feedback
12:38:49 <sdague> as I don't think anyone has said that crytalizing the current interface is a good idea
12:40:12 <sdague> ok, anything else today?
12:40:17 <sdague> we seem to have stalled out
12:40:20 <eliqiao> yes
12:40:24 <eliqiao> I got one bug.
12:40:31 <sdague> eliqiao: ok, cool
12:40:35 <eliqiao> #link https://bugs.launchpad.net/nova/+bug/1536513
12:40:35 <openstack> Launchpad bug 1536513 in OpenStack Compute (nova) "os-getConsoleOutput fail with 500" [Medium,Confirmed] - Assigned to Eli Qiao (taget-9)
12:41:12 <eliqiao> The thing is, we don't handler that exception in REST API layer.
12:41:23 <sdague> yeh, that seems like a thing we should fix
12:41:28 <eliqiao> And neither do compute api layer.
12:41:33 <sdague> also, I think it should be a 404 not a 400
12:41:45 <sdague> because it's a console doesn't exist for that guest, right?
12:41:52 <alex_xu> I think we should check more detail, ensure the virt driver raise a useful exception
12:42:01 <eliqiao> sdague: not all drivers raise same exception for example  https://github.com/openstack/nova/blob/master/nova/virt/hyperv/vmops.py#L667
12:42:14 <eliqiao> sdague: for others, they raise NovaException.
12:42:31 <sdague> eliqiao: ok, I would suggest making a standard exception for that
12:42:42 <sdague> and getting all the virt drivers use that
12:42:53 <cdent> drivers should cast to unified exception themselves and reraise yeah?
12:42:53 <sdague> maybe a couple, depending on the failure modes
12:43:15 <alex_xu> sdague: sometime people just raise NovaException for unexpected error, and we should return 500 for unexpected error?
12:43:21 <sdague> cdent: right, some kind of detail that can be translated at the top layer
12:43:41 <sdague> alex_xu: I think that's probably ok in general
12:43:50 <eliqiao> yeah, I think we need to deep into driver case by case.
12:43:56 <sdague> as we see these issues, we should try to make them more defined behavior
12:44:44 <eliqiao> sdague: I am think that in compute api layer(or compute manager) catch exception then do a reraise?
12:44:46 <alex_xu> sdague: ok, just afriad that will hide some bug
12:45:02 <sdague> alex_xu: a 500 error is always a bug
12:45:11 <sdague> we even tell people to report them all
12:45:31 <eliqiao> hmm... yeah, we do have that information to remine them to report bug...
12:45:36 <alex_xu> sdague: so for RPC timeout, should we catch them?
12:45:53 <sdague> alex_xu: was that the root issue here? and RPC timeout?
12:45:59 <eliqiao> but somthime it's the driver itself's issue not of nova...
12:45:59 <sdague> this is my first look at this bug
12:46:00 <alex_xu> sdague: maybe timeout just for huge load
12:46:31 <sdague> ok, what do you believe the root issue is here?
12:46:46 <sdague> maybe we can work backwards from there, because I think I've gotten myself turned around
12:47:04 <eliqiao> sdague: alex_xu or other folks, can you help to leave some comments on that bug.
12:47:07 <alex_xu> sdague: ok
12:47:16 <sdague> eliqiao: sure, yeh, lets just leave comments on the bug
12:47:31 <eliqiao> sdague: thx.
12:47:52 <jichen> https://github.com/openstack/api-wg/blob/master/guidelines/http.rst, API wg has some comments on the MessageQueueTimeout
12:48:18 <jichen> seems in their guideline 500 is acceptable if timeout
12:49:00 <sdague> jichen: I think in some cases that's fine
12:49:09 <jichen> sdague: ok
12:49:23 <jichen> I got one issue if eli's is done
12:49:23 <sdague> 5xx is really supposed to mean "your servers are broken / breaking"
12:49:24 <jichen> https://review.openstack.org/#/c/276144/
12:49:36 <sdague> hitting rpc timeouts seems to be in that camp
12:49:46 <jichen> yeah
12:50:15 <alex_xu> sdague: yea, that is what i'm thinking, some exception raise because server broken
12:50:59 <sdague> jichen: what does neutron return in these cases?
12:51:00 <jichen> my question is whether we need microversion if change from 503 to 409 , our microversion document didn't mention it's aceeptable to do this without microversion
12:51:06 <eliqiao> alex_xu: does server mean nova?
12:51:19 <gmann_> jichen: not needed in v2.1?
12:51:21 <eliqiao> alex_xu: what if lowlevel broken?
12:51:26 <alex_xu> eliqiao: yeah, or the component of nova
12:51:46 <sdague> jichen: I think we ended up with not needed when downgrading a 500 error
12:51:53 <jichen> gmann_ : I changed v2.1 code
12:52:05 <jichen> sdague: you mean 5xx error?
12:52:08 <sdague> yes
12:52:12 <jichen> ok
12:52:29 <sdague> I can comment back on it
12:52:40 <sdague> I was already +2 on it
12:52:49 <sdague> ok, anything else?
12:52:50 <jichen> I don't have chance to try neutron, will try and update it in the patch
12:52:59 <jichen> also, I will write a follow up to change the microversion doc
12:53:06 <johnthetubaguy> I have a feeling we said no bump if its an existing error message, but yeah, removing a 500 seems like another case we shouldn't have to bump
12:53:17 <johnthetubaguy> we wouldn't want to leave the 5xx error in the old API versions, thats the key bit
12:54:00 <cdent> johnthetubaguy++
12:54:13 <jichen> +1
12:54:45 <gmann_> i too +1 on not version bump for 500 fix, but we should update doc too
12:55:28 <jichen> yeah
12:55:28 <alex_xu> +1
12:55:33 <eliqiao> +1
12:55:42 <alex_xu> I remember our devref said that
12:56:01 <eliqiao> yeah, it's bug fixing, so no bump
12:56:20 <alex_xu> ok, anyway, no more from me
12:56:25 <johnthetubaguy> " Fixing a bug so that a 400+ code is returned rather than a 500 does not require a microversion change."
12:56:30 <johnthetubaguy> http://docs.openstack.org/developer/nova/api_microversion_dev.html
12:56:56 <alex_xu> johnthetubaguy: cool, thanks
12:57:15 <sdague> ok, anything else?
12:57:25 <alex_xu> nothing from me
12:57:29 <eliqiao> not from my side.
12:57:44 <alex_xu> 3...
12:57:46 <alex_xu> 2..
12:57:49 <alex_xu> 1.
12:57:51 <alex_xu> thanks all!
12:57:52 <eliqiao> bye
12:57:54 <alex_xu> #endmeeting