13:00:03 <alex_xu> #startmeeting nova api
13:00:04 <openstack> Meeting started Wed Apr 20 13:00:03 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:09 <openstack> The meeting name has been set to 'nova_api'
13:00:14 <alex_xu> who is here today?
13:00:28 <jichen> o/
13:00:33 <cdent> o/
13:00:33 <gmann_> o/
13:01:10 <oomichi_> hi
13:01:28 <alex_xu> let's start the meeting
13:01:36 <sdague> o/
13:01:40 <alex_xu> #topic API Priorities
13:02:13 <alex_xu> For api policy discovery, I guess no more update last week?
13:02:28 <sdague> alex_xu: I think it's just about the specs right now
13:02:46 <sdague> the policy in code spec seems pretty solid, a good starting point for summit
13:02:56 <alex_xu> sdague: yea, i think so
13:03:02 <alex_xu> so just jump to api ref
13:03:07 <sdague> the policy over the API has concerns about formatting that cdent brought up
13:03:30 * alex_xu always jump at wrong time
13:03:32 <sdague> I think that's the interesting question about whether exposing the policy raw format this cycle is a step forward or back
13:03:57 <johnthetubaguy> honestly, it feels like it might be worth a cycle to tidy up policy before we expose it
13:04:02 <sdague> I put an alternative that we could do the plumbing, put in a conf option to expose it (off by default)
13:04:08 <alex_xu> if there is good propose, i think we can use it instead of raw format
13:04:27 <sdague> alex_xu: well, the challenge is getting that format is going to be a while I think
13:04:55 <sdague> but I think we're going to learn a lot in actually putting it on the wire
13:05:14 <sdague> so I'd still like to do that work, even if off by default, and we tell people this format isn't guarunteed
13:05:20 <alex_xu> sdague: yea
13:05:24 <cdent> seems reasonable
13:05:35 <johnthetubaguy> sdague: could we make use of the experimental API flag for this?
13:05:37 <sdague> anyway, I left that as a comment on the review
13:05:37 <gmann_> as experimental
13:05:44 <cdent> we've had issues in the past, though, with exposed stuff becoming natural defaults despite warnings
13:05:49 <sdague> johnthetubaguy: honestly, I wouldn't even do that
13:05:57 <sdague> I would not document this API
13:06:06 <sdague> it will be turned on / off by a CONF variable
13:06:14 <sdague> it will default off
13:06:27 <cdent> I think that's a good way to get the experience of making it happen without the danger of people adapting to it
13:06:45 <johnthetubaguy> OK, yeah, I am warming to that idea
13:06:50 <gmann_> +1, without putting it in doc is safe side
13:06:51 <oomichi_> sdague: that means the exposing api is added without microversion bump
13:06:52 <sdague> yeh, we could even emit a warning in the logs if the conf it turned on
13:06:58 <johnthetubaguy> we no a big band approach almost always fails, this would let us evolve it
13:07:36 <johnthetubaguy> oops s/band/bang/
13:07:50 <sdague> oomichi_: I get that is strictly true
13:07:51 <cdent> it's only natural you'd make that mistake johnthetubaguy
13:07:58 <johnthetubaguy> cdent: heh
13:07:59 * cdent oompahs
13:08:22 <oomichi_> interesting approach for me
13:08:24 <sdague> I think if we basically make this a WARNing to turn on, we're going to say we don't believe this exists at this point
13:08:42 <sdague> the REST semantics of the resources should be basically fixed at this
13:08:50 <sdague> at this point, it's the payload that isn't
13:08:53 <sdague> which is the problem
13:09:16 <sdague> once we get the payload we like, this goes on unconditionally, then we do the microversion bump
13:10:10 <johnthetubaguy> sdague: I honestly quite like the president this sets, it seems worth a go
13:10:11 <sdague> anyway, that's the best idea I've got in how to make incremental and forward progress here
13:10:21 * edleafe stumbles in late
13:10:35 <sdague> johnthetubaguy: ok, cool
13:10:42 <alex_xu> sounds good plan
13:10:47 <oomichi_> sdague: that is a new way to use microversion, +1
13:11:18 <johnthetubaguy> the microversion bump means any tooling that users the final has to be different to stuff accessing the experimental stuff, but thats perfect
13:11:46 <johnthetubaguy> that solves the need I was thinking adding the experimental API flag would fix
13:11:46 <sdague> ok, we should probably write this plan back into the spec
13:11:56 <sdague> anyone want to volunteer for that?
13:12:00 <sdague> claudio_ here?
13:12:01 * johnthetubaguy hopes the bot got all that
13:12:14 <gmann_> even we can adopt that in future for other such case we need time to setup the things
13:12:16 <sdague> johnthetubaguy: I'm sure it did, but we should condense it back
13:12:30 <johnthetubaguy> sdague: totally
13:12:39 <sdague> gmann_: yeh, I was thinking the same thing. We'll see how terrible an idea it turns out to be.
13:13:06 <sdague> volunteer to update the spec?
13:13:15 <cdent> I can do it
13:13:24 <sdague> cdent: thanks!
13:13:26 <gmann_> sdague: yea, that's nice
13:13:39 * alex_xu typing slow, and lose than cdent
13:13:47 <alex_xu> cdent: thanks!
13:13:56 <sdague> ok, I think that one is done, next topic?
13:14:16 <alex_xu> yes, should be the api ref
13:14:16 <cdent> #action cdent to update policy over api spec to reflect pre-microversion handling
13:14:31 <alex_xu> cdent: thanks again
13:15:17 <alex_xu> looks like good progress on api-ref, a lot of fix for doc recently
13:15:57 <gmann_> alex_xu: yea just ran tox and seems like we left with baremetal etc which sdague has patch up
13:16:15 <alex_xu> that is cool
13:16:20 <alex_xu> sdague: what is next plan?
13:16:46 <gmann_> alex_xu: sdague we need response parameter addition for most of them
13:16:47 <sdague> alex_xu: there are still some warnings to get purged so we can turn warnings into errors
13:17:11 <sdague> right, then we move into the content phase and actually need to go through each of the parameters lists and make sure they match up correctly
13:17:24 <gmann_> yea
13:17:29 <sdague> I had that 4 step process for each file
13:17:30 <jichen> +1
13:17:45 <sdague> auggy was working on some tools to generate bugs for these, but it's going a bit slow
13:18:20 <sdague> so I was kind of wondering if we should instead set a set of comments at the top of each file for the for 4 steps needed
13:18:34 <sdague> then when we believe each bit is done we remove that comment
13:18:41 <sdague> as a way to track work
13:19:15 <sdague> I was kind of wondering what opinions people wanted to have here
13:19:31 <sdague> because it was great to get so many folks helping with samples files cleanup
13:19:32 <alex_xu> i like that idea, at least better than etherpad
13:19:47 <sdague> yeh, giant etherpads kind of suck
13:20:17 <johnthetubaguy> I like removing lines in the file as work is done
13:20:22 <gmann_> sounds good, fix or audit can keep removing those
13:20:46 <johnthetubaguy> as long as the merge conflicts are not terrible, and sounds like it should be OK in this case?
13:20:59 <sdague> ok, I can get those built today, as well as a wiki page with detailed instructions on what we expect
13:21:07 <sdague> johnthetubaguy: yeh, they aren't terrible
13:21:17 <sdague> the biggest thing you need to do is keep an eye on open patches
13:21:29 <johnthetubaguy> this feels like something we can get OSIC to help with, alex_xu do you agree?
13:21:43 <johnthetubaguy> yeah, yet a topic folks are checking like the centralise config work
13:21:46 <alex_xu> johnthetubaguy: yea, agree, that will help a lot
13:21:58 <johnthetubaguy> alex_xu: I will try get that added on the list
13:22:09 <alex_xu> johnthetubaguy: cool
13:22:28 <sdague> I've also moved to doing fast approve (single +2) for most of these changes, to help on that. Because keeping the outstadning patches low is part of how we avoid merge conflicts
13:22:36 <sdague> bp:api-ref-in-rst
13:22:42 <sdague> is the blueprint / topic for this work
13:22:51 <sdague> and I look at that a couple times a day now
13:23:02 <gmann_> sdague: yea that helped a lot
13:23:14 <gmann_> fast merge
13:23:33 <sdague> we've managed to get a lot done pretty quickly already
13:23:37 <sdague> which is awesome
13:23:43 <alex_xu> +1
13:23:47 <sdague> thanks to everyone here for those patches and reviews
13:24:08 <sdague> ok, so here I think is the concrete next steps
13:24:38 <sdague> #action sdague to create wiki page documenting the content checks that should be done for every file
13:25:11 <sdague> #action sdague to push comments into all inc files saying that they all need to go through this
13:25:13 <gmann_> sdague:  also you are turning warning to error right?
13:25:26 <sdague> gmann_: as soon as I get these last warnings closed
13:25:31 <sdague> I think I'm down to 22 locally
13:25:36 <gmann_> ok
13:26:07 <sdague> gmann_, alex_xu, jichen it's late there right, I'm assuming that you all are pretty much done for the day
13:26:15 <sdague> so I can try to get that all sorted before your tomorrow
13:26:20 <sdague> so that you can run at things then
13:26:35 <gmann_> sdague: yea, that will be nice.  +1
13:26:39 <alex_xu> sdague: yea, sounds cool
13:26:47 <jichen> sdague: ok, thx
13:27:29 * mriedem joins a half hour late
13:27:45 <sdague> I guess, the other question I have is are there people not comming to summit? Because I'd like to make it so we could still make progress with patches next week if people are not at summit and want to make patches.
13:28:08 <jichen> I will not go to because of VISA issue
13:28:47 <sdague> jichen: ok, I'll make sure to review api-ref patches every morning at summit, so feel free to push them and we'll still try to land those next week
13:29:04 <jichen> sdague: ok, thanks !
13:29:22 * alex_xu will try also if he can get enough sleep
13:29:30 <jichen> :)
13:29:41 <alex_xu> or i can't sleep
13:29:53 <sdague> :)
13:30:04 <gmann_> that's good option :)
13:30:24 <sdague> ok, cool. any other questions on the api-ref work?
13:30:30 <cdent> sdague: I'm won't be at summit, but I'm taking most of next week off, so won't be ablle to help (with that).
13:30:43 <sdague> also, http://developer.openstack.org/api-ref/compute/ is live and gets updated on every merge
13:30:54 <sdague> so we can see the whole thing evolving
13:32:07 <sdague> if no other questions, I think we're done with this topic
13:32:12 <alex_xu> that is surprised me
13:32:13 <johnthetubaguy> sdague: awesome to see that there :)
13:32:25 <alex_xu> #topic open
13:32:43 <alex_xu> #link https://review.openstack.org/#/c/308026/
13:32:47 <alex_xu> cdent: i guess this is yours
13:33:01 <cdent> ah, yeah, I just wanted to point out it was athere
13:33:21 <cdent> but it seems likely that for at least now the alternative of "do nothing" might be the best bet
13:33:36 <cdent> it depends on how people feel about the proposed solution (which is localised to just one file)
13:35:12 <sdague> cdent: theory question, if nova used flask instead of it's home grown wsgi stack, would this be a solved problem for us?
13:35:56 <cdent> It depends in part on how the routing was done, but for the usual case, yes
13:36:48 <johnthetubaguy> did we agree 404->405 doesn't need a microversion bump?
13:36:53 <sdague> items like this I'd rather solve by getting nova over to flask as a long term goal
13:37:21 <cdent> sdague: I think that's a _huge_ task
13:37:26 <sdague> cdent: I agree
13:37:42 <sdague> however, I think that once we can delete legacyv2 stack
13:37:46 <cdent> the way nova does wsgi is so wrapped up in itself is only part of the problem
13:37:57 <cdent> the other half of the problem is that flask is not really wsgi
13:37:58 <alex_xu> i guess just one line fix for current homemade wsgi stack?
13:38:03 <sdague> and we can actually remove the extensions facility entirely
13:38:13 <oomichi_> current tempest also is testing based on 404 expectation on the other services also
13:38:23 <johnthetubaguy> sdague: +1
13:38:27 <oomichi_> this affects huge area
13:38:28 <sdague> alex_xu: is it, I thought there was a bunch of open questions on how routes handles things
13:38:45 <sdague> oomichi_: I'm not convinced tempest is testing this bit at all
13:39:04 <sdague> this is a set of negative space that no one has really thought to poke
13:39:04 <cdent> it's slightly more than one line, but the lines can all be in one place
13:39:50 <oomichi_> sdague: ok, but this behavior seems on many other services
13:40:04 <sdague> oomichi_: well, not really
13:40:11 <sdague> lots of places use 405 incorrectly :)
13:40:16 <sdague> including us I think
13:40:26 <alex_xu> cdent: ok, i just though 'not supported method' means there isn't a route for it.
13:40:41 <oomichi_> yeah, I agree :)
13:40:42 <sdague> it also seems weird to make this change before our 405/501 are handled
13:40:56 <cdent> alex_xu: routes will return none when there is a route, but no method and when there is no route, which mean different things
13:41:17 <sdague> because that seems to further confuse what method not found means
13:41:59 <cdent> the reason I landed on this particular issue was because it is somewhat localized: the "problem" happens before entering the actual service apps (it happens in middleware)
13:42:14 <cdent> so it is more straightforward to fix than some of the other problems
13:42:35 <cdent> the complexity comes in on the expected impact on users and performance
13:43:00 <sdague> cdent: right, but it does I think create more confusion given that we still have incorrect 405/501 usage. Because we are overloading those before removing the old wrong use.
13:43:33 * cdent nods
13:43:54 <cdent> Well, the spec is there if we wish to pursue it. There wasn't a lot of time lost in writing it and it will keep.
13:44:14 <cdent> I also have similar questions to a semi-related bug: https://review.openstack.org/#/c/304958/
13:44:17 <sdague> ok, cool, up for comment by folks
13:44:20 <cdent> s/bug/bug fix/
13:44:52 <cdent> there's debate on that about the need for microversion. The author has come to me seeking clarification since he thought the need was resolved
13:45:06 <sdague> https://review.openstack.org/#/c/304958 seems like a straigh up bugfix to me honestly
13:45:12 <cdent> I let him know, since he is new to openstack, that it takes several rounds for any question/conversation to clearly resolve
13:45:26 <cdent> as additional people join into the process
13:45:35 <sdague> my comment on April 13 I think was clear there
13:45:58 <cdent> sdague: yes, but followups de-clarified it
13:46:30 <johnthetubaguy> did the v2.1 version fix this already?
13:46:33 <sdague> ok, I hadn't seen the unit test fixes
13:46:42 <sdague> johnthetubaguy: no, this happens super early in processing
13:46:49 <alex_xu> i think we agree on fix it without microversion, looks like clearly
13:46:53 <sdague> https://review.openstack.org/#/c/304958/4/nova/api/openstack/wsgi.py
13:47:00 <sdague> ok, I just +2ed it
13:47:06 <johnthetubaguy> sdague: oh, I see now, thanks
13:47:23 <cdent> edleafe: do you want re-present your concerns or are you satisfied?
13:47:24 <sdague> so anyone else that wants to approve, please do so
13:47:35 * alex_xu will try after the meeting
13:47:52 <gmann_> then we need backport for kilo/liberty/mitaka ?
13:47:54 <edleafe> cdent: no, if it is considered a bug fix
13:48:05 <cdent> cool
13:48:09 <cdent> or even
13:48:11 <cdent> k3wl
13:48:12 <sdague> gmann_: yeh, it's definitely up for that
13:48:26 <sdague> gmann_: you want to propose backports once we land this in master?
13:48:42 <gmann_> sdague: sure but tomorrow morning only
13:48:47 <sdague> gmann_: yeh, that's fine
13:48:50 <sdague> no rush
13:48:54 <gmann_> ok
13:49:00 <mriedem> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
13:49:05 <mriedem> Changing an error response code to be more accurate.
13:49:08 <mriedem> this falls under that
13:49:15 <mriedem> "The following types of changes are generally considered acceptable:"
13:49:19 <sdague> yep
13:49:33 <mriedem> the confusion probably comes from our microversion docs
13:49:44 <mriedem> about changing error codes that weren't previously returned
13:50:08 <mriedem> we might want to use this as a test against that doc
13:50:12 <mriedem> to see if it makes sense
13:50:41 <sdague> yeh, honestly, we might want to remove that bit, I feel like most of the time that's just caused more confusion than it's helped with
13:50:47 <mriedem> http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion
13:50:51 <mriedem> the response section is the confusing part
13:50:54 <sdague> yeh
13:50:57 <mriedem> the list of status codes allowed for a particular request
13:52:37 <alex_xu> looks like hard to form a doc to guide all the cases
13:52:46 <sdague> right, sometimes we just need humans :)
13:53:00 <mriedem> at some point there will be a robot with common sense
13:53:06 <mriedem> and it will rule the world
13:53:07 <alex_xu> that is something i hope we have one intially, but that is failed
13:53:08 <cdent> DEATH TO ALL HUMANS
13:53:12 <gmann_> heh
13:53:17 <cdent> (is what a robot with common sense will say)
13:53:53 <mriedem> maybe we just add 415 to this list of exceptions http://docs.openstack.org/developer/nova/api_microversion_dev.html#f2
13:54:00 <mriedem> that's an easy compromise
13:54:02 <alex_xu> sdague: is there more restrict way to review which api change needn't microversion?
13:54:19 <sdague> alex_xu: can you rephrase the question?
13:54:46 <sdague> mriedem: sure we could, I also think that items like this need to ponder the client fallout
13:55:17 <sdague> in this case, the odds that someone is pushing random content types and requiring a 400 to tell them they pushed gorp, is highly unlikely
13:55:28 <alex_xu> sdague: sorry, we have spec to describe the api change with microversion, what about without microversion? but I definitly don't want another spec for it.
13:55:44 <sdague> and being more specific with a 415 actually helps someone debug their application
13:55:50 <sdague> because it helps tell them what they did wrong
13:56:00 <mriedem> yeah, i've approved the change and marked the bug as backportable for mitaka and liberty
13:56:04 <johnthetubaguy> yeah, its more when the user gets more information, and can change their "resolution" of the error, that its useful to know whats going on, I guess?
13:56:38 <sdague> right, I feel like another giant attempt to build a finite state machine for review judgement for all possible changes isn't really fruitful
13:56:52 <johnthetubaguy> sdague: ack
13:56:53 <sdague> there is a time and a place for human judgement and consideration
13:56:58 <alex_xu> ok :)
13:56:59 <sdague> this is one of them
13:57:06 <gmann_> yea
13:57:33 * alex_xu reminder 3 mins left
13:57:57 <sdague> ok, so I've got a change up, that people should think about, and hits another one of these judgments
13:58:02 <sdague> https://review.openstack.org/#/c/307186/
13:58:12 * alex_xu window bare
13:58:16 <alex_xu> oops
13:58:23 <sdague> which is based on bug - https://bugs.launchpad.net/nova/+bug/1567621
13:58:24 <openstack> Launchpad bug 1567621 in OpenStack Compute (nova) "Scripts requesting v3 get multiple choices with bad URLs" [Medium,In progress] - Assigned to Sean Dague (sdague)
13:58:42 <sdague> the issue is that weird 300 multi option return we have
13:58:55 <sdague> which, is very unlikely to be useful to anyone
13:59:07 <alex_xu> ok, let's review it
13:59:18 <sdague> it is exposed by links [ type: bookmark ] in servers, flavors, images
13:59:19 <alex_xu> ok, last meessage, we will cancel next week meeting
13:59:30 <alex_xu> and seeing you guys in Austin
13:59:33 <cdent> sdague++ on kill 300 weirdness
13:59:46 <alex_xu> it's time close the meeting
13:59:49 <alex_xu> thanks all
13:59:52 <alex_xu> #endmeeting