14:00:29 <johnthetubaguy> #startmeeting nova
14:00:30 <ujuc> sorry late.
14:00:31 <openstack> Meeting started Thu Aug 20 14:00:29 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:35 <FdotFr> Daisy thank you Daisy  :)
14:00:35 <openstack> The meeting name has been set to 'nova'
14:00:45 <alaski> o/
14:00:50 <johnthetubaguy> hello all
14:00:53 <andreykurilin> \o
14:00:54 <rlrossit> o/
14:00:55 <claudiub> o/
14:00:56 <edleafe> o/
14:00:57 <markus_z> o/
14:00:58 <jroll> \o
14:00:58 <n0ano> o/
14:00:59 <mnestratov|2> o/
14:01:00 <johnthetubaguy> #topic Release Status
14:01:01 <dansmith> o/ (for five minutes)
14:01:19 <atuvenie> o/
14:01:34 <jichen> o/
14:01:37 <sudipto> o/
14:01:41 <lpetrut> o/
14:01:55 <johnthetubaguy> #info liberty-3 is expected on September 1st
14:01:59 <jlvillal> o/
14:02:00 <johnthetubaguy> thats the next big date
14:02:09 <johnthetubaguy> where we get string freeze, etc
14:02:14 <bauzas> \o
14:02:15 <johnthetubaguy> and its the final full feature freeze
14:02:39 <mriedem> o.
14:02:43 <mriedem> o/ even
14:02:45 <johnthetubaguy> I decided to skip the priority feature proposal freeze as such, letting the individual groups deal with that in there own way
14:02:59 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
14:03:08 <johnthetubaguy> #topic Bugs
14:03:18 <johnthetubaguy> so lets talk bugs
14:03:24 <johnthetubaguy> markus_z: any updates?
14:03:27 <markus_z> one solved critical, high prio bugs seem to get more
14:03:47 <dims> o/
14:03:53 <johnthetubaguy> clearly its a great time to start reviewing lots of bug fixes
14:03:54 <markus_z> Many of the high prio things are pretty old, I will go through the list
14:04:01 <johnthetubaguy> mriedem: anything on gate stats?
14:04:15 <mriedem> well,
14:04:20 <johnthetubaguy> (and/or stable)
14:04:26 <mriedem> the logstash job queue has been wonky for about a week,
14:04:43 <mriedem> so we don't have great numbers on the current state of the gate - there is some new neutron thing blowing up stuff with a race updating quotas on the neutron side
14:04:48 <mriedem> https://bugs.launchpad.net/neutron/+bug/1485969
14:04:48 <openstack> Launchpad bug 1485969 in neutron "test_dualnet_multi_prefix_dhcpv6_stateless failed due to "RuntimeError: Set changed size during iteration" in quota code" [Undecided,In progress] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
14:04:58 <mriedem> but since we don't have logstash indexes i don't know how prevalant that is
14:05:17 <johnthetubaguy> ah... so blind right now
14:05:17 <mriedem> clarkb said there is a fix working it's way through and then we should be back to knowing the state of the world
14:05:21 <mriedem> sort of yeah
14:05:28 <johnthetubaguy> OK, thats good news I guess
14:05:42 <mriedem> for stable, kilo is ok i think, there are a few changes out for review
14:06:04 <mriedem> juno has some issues with devstack and capped/uncapped dep conflicts which tonyb was pursuing a fix for
14:06:14 <mriedem> i'm not sure if that's wedging all of juno though, i haven't dug in that far
14:06:17 <johnthetubaguy> mriedem: is it worth us talking about stable releases at all?
14:06:25 <mriedem> probably not
14:06:31 <mriedem> there isn't concensus there yet
14:06:40 <johnthetubaguy> yeah, I guess, join in the fun on the ML if you are interested
14:06:46 <johnthetubaguy> cools, any more on that stuff?
14:06:49 <mriedem> nope
14:06:57 <johnthetubaguy> thanks mriedem and markus_z
14:07:02 <johnthetubaguy> #topic Reminders
14:07:08 <johnthetubaguy> #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:07:14 <johnthetubaguy> lets keep revieweing the above list
14:07:25 <johnthetubaguy> and doing post summit actions
14:07:31 <johnthetubaguy> #link https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items
14:07:42 <johnthetubaguy> #topic Open Discussion
14:07:49 <mriedem> we need more trivial bugs in the priorities etherpad :)
14:07:53 <johnthetubaguy> so I don't see any tuck reviews, to straight to opne
14:08:02 <dims> mriedem: ack will do one today
14:08:05 <johnthetubaguy> mriedem: thats true, dims did you find people to help you with that?
14:08:11 <bauzas> well, we had some discussion on a review
14:08:19 <bauzas> but it's no longer stuck I guess
14:08:35 <johnthetubaguy> #help need people to help dims add trival bugs into https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:08:39 <mriedem> there are 2 trivial bugs in the list atm
14:08:46 <bauzas> mriedem: I guess some of us will have more time to chase bugs post-FF :)
14:08:50 <mriedem> subteam change lists are also pretty short
14:08:57 <dims> johnthetubaguy: thanks
14:08:58 <mriedem> bauzas: we were post FF a couple of weeks ago
14:09:07 <johnthetubaguy> yeah, they are all starting to run try, although thats good really
14:09:09 <dims> johnthetubaguy: when do we yank ec2 stuff?
14:09:17 <johnthetubaguy> mriedem: well that was non-priority feature freeze, but yeah
14:09:20 <bauzas> mriedem: post-FF for non-prio stuff but
14:09:43 <johnthetubaguy> dims: I think we were still waiting for ops feedback, I think cern promised to supply some after there upgrade
14:10:04 <dims> k thanks
14:10:23 <mriedem> i have 2 things on open discussion
14:10:28 <johnthetubaguy> dims: appreciate people checking though, don't want to forget that
14:10:31 <johnthetubaguy> mriedem: yup
14:10:44 <johnthetubaguy> mriedem: so 500 response stuff?
14:10:44 <mriedem> first is about when a microversoin is needed, http://lists.openstack.org/pipermail/openstack-dev/2015-August/072448.html
14:10:46 <mriedem> yeah
14:11:00 <johnthetubaguy> its a good point
14:11:00 <mriedem> there are 2 changes, both handle turning a 500 into a 400+ error
14:11:08 <mriedem> which used to be totally fine as a bug fix in v2 land
14:11:15 <johnthetubaguy> I replied this morning, on a middle ground
14:11:21 <mriedem> i haven't caught up on the ML yet
14:11:27 <mriedem> but my questions are in the meeting agenda
14:11:33 <johnthetubaguy> mriedem: what about a version bump without a spec, just to advertise the change?
14:11:43 <mriedem> but how is the bug fixed in v2 api?
14:11:45 <mriedem> or is it not?
14:11:50 <johnthetubaguy> but we backport the change to all previous versions too
14:11:53 <johnthetubaguy> I missed that bit
14:12:21 <mriedem> i guess v2 gets the same error code that v2.1 gets
14:12:23 <johnthetubaguy> so the original thinking was, new error code, best let people know via an API bump
14:12:30 <mriedem> but why is that?
14:12:41 <mriedem> i believe tempest handles anything over 400 as an error
14:12:44 <johnthetubaguy> mriedem: just so they know its something they can now expect
14:12:47 <mriedem> i'd expect most clients to do similar
14:12:54 <johnthetubaguy> mriedem: but not all clients do that, I think thats the thinking
14:13:03 <mriedem> if a client is handling each 400+ one by one, they are nuts
14:13:05 <johnthetubaguy> its more because we can, rather than anything else
14:13:14 <mriedem> just because we can't doesn't mean we should
14:13:15 <jichen> mriedem: Alex added some comments on http://lists.openstack.org/pipermail/openstack-dev/2015-August/072520.html
14:13:17 <johnthetubaguy> mriedem: some can be retried in a different way though
14:13:23 <johnthetubaguy> not that we get that right
14:13:27 <mriedem> sure, but
14:13:31 <alaski> I would think that a 500 error to something else wouldn't require a bump
14:13:44 <jichen> +1
14:13:53 <mriedem> i'd think that most clients, like our actual client libs, would have some central error handling for all API responses
14:14:03 <mriedem> not just some specific one about creating volumes
14:14:14 <mriedem> it would be madness to try and sync those up
14:14:15 <johnthetubaguy> alaski: I think we originally we said, yes, as long as its an existing error code for that API call
14:14:40 <johnthetubaguy> so I think you are right
14:14:47 <mriedem> idk, i'm definitely not sold on that - and if that's the reasoning i think it needs to be documented in the devref about when to add a microversion in those cases
14:15:04 <johnthetubaguy> my preference is, advertise the fix in an API bump, but fix the return code in all API versions
14:15:20 <mriedem> in one of these patches jichen could have used an existing 400 but it's overquote and the api-wg docs say to treat those as 403, which would be new in that extension
14:15:29 <mriedem> and according ot our docs that's yet another microversion
14:15:57 <johnthetubaguy> yeah, I am saying lets go for a middle ground, fix the error code for all API versions, do a bump just to advertise the fix
14:16:16 <johnthetubaguy> (advertise the fix, incase someone wants to rely on that error code to do something fancy)
14:16:17 <mriedem> so the other question is, how are microversion bug fixes like this in v2.1 in liberty backported to kilo?
14:16:37 <alaski> johnthetubaguy: I'm not sure I see the value in the bump if the error changes on previous versions
14:16:38 <mriedem> since we can't just go from 2.3 in kilo to 2.13
14:16:57 <johnthetubaguy> mriedem: honestly, thats a good question, don't think we have an answer for backports
14:17:05 <mriedem> i suggested 2.3.1
14:17:09 <mriedem> in kilo
14:17:24 <johnthetubaguy> mriedem: hmm, I quite like that actually
14:17:34 <mriedem> i do'nt think jichen actually plans on backporting these, but it is something we used to do for 500->400 fixes
14:17:34 <jaypipes> hey guys, sorry I'm late :(
14:17:50 <mriedem> just in time
14:17:52 <johnthetubaguy> alaski: its minimal value, its just signalling to users because we can, really
14:17:56 <mriedem> since i'd also like jaypipes' input
14:17:59 <jichen> mriedem: I can do
14:18:00 <alaski> mriedem: we would need to forward port that as well right?
14:18:02 <johnthetubaguy> +1
14:18:11 <jaypipes> mriedem: so I've been thinking on that exact thing since reading alex_xu's response this morning.
14:18:15 <johnthetubaguy> +1 to jaypipes input on this
14:18:17 <mriedem> sdague said he wouldn't make the meeting today but he should also have input here
14:18:19 <alaski> mriedem: so 2.3.1 doesn't stop working
14:18:48 <mriedem> alaski: forward port the 2.3.1 to liberty?
14:18:52 <mriedem> so 3 changes for one bug fix?
14:18:53 <mriedem> ew
14:18:59 <alaski> yeah
14:19:14 <mriedem> i guess you'd have 2.13 for liberty, 2.3.1 in liberty for backport to kilo
14:19:22 <mriedem> but basically the same code
14:19:26 <alaski> was this really not discussed on the original specs?
14:19:35 <johnthetubaguy> ouch, that fails doesn't it
14:19:37 * alex_xu forget the meeting
14:19:39 <rlrossit> would it be possible to just make a 2.3.1 in liberty, or do we actually need the 2.13 bump?
14:19:50 <mriedem> idk
14:20:00 <mriedem> aparently we haven't thought through backports
14:20:11 <johnthetubaguy> alaski: we kinda skipped the "when to bump" thing, and I guess we accidentally skipped backports in the process :(
14:20:21 <alex_xu> if we treat 500 as contract, we needn't backport
14:20:22 <bauzas> I thought the .z stuff was -1'd nope ?
14:20:24 <mriedem> we could table the backport discussion so we don't bikeshed here
14:20:35 <alaski> is there any reason we can't just backport the same version?
14:20:48 <mriedem> i'm mostly interested in not overprocessing a stupid simple fix to handle a 500
14:20:55 <jaypipes> alex_xu: the 500 stuff is *never* contractual, though. it's always considered a bug (that does not need a microversion bump) when something returns a 500.
14:20:55 <johnthetubaguy> alaski: we assume we have all versions in between right now
14:21:08 <alaski> johnthetubaguy: can we relax that assumption?
14:21:13 <johnthetubaguy> jaypipes: +1 on the 500 error never being a contract
14:21:15 <mriedem> jaypipes: "it's always considered a bug (that does not need a microversion bump) when something returns a 500." is not what our devref says
14:21:27 <jaypipes> alex_xu: what *does* need a microvesion is when we change something from 4XX to some other 4XX
14:21:30 <johnthetubaguy> alaski: not sure we can given how we report the min/max versions of the API
14:21:41 <jaypipes> mriedem: the API WG devref or the Nova one?
14:21:44 <mriedem> nova
14:21:59 <mriedem> http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n68
14:22:18 <mriedem> http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63 also applies here
14:22:21 <alex_xu> jaypipes: but user may, when user saw the 500, user may based on the response to detech what kind of error
14:22:34 <johnthetubaguy> mriedem: so for backports, maybe all microversion bumps are "features", so there should never by any backports, but that means relaxing some of the rules, I guess
14:23:00 <mriedem> johnthetubaguy: but that basically means you can't ever fix api bugs on stable
14:23:27 <johnthetubaguy> mriedem: well can't fix any bugs that change the API version, we can backport the others
14:23:30 <mriedem> http://weknowmemes.com/wp-content/uploads/2012/01/has-the-whole-world-gone-crazy.jpg
14:23:32 <jaypipes> alex_xu: client code should *never* be *expecting* a 500 error.
14:23:54 <johnthetubaguy> jaypipes: +1
14:24:17 <alex_xu> jaypipes: yea, I agree, but when you access an bug openstack deployement, he may want to bypass that
14:24:25 <johnthetubaguy> so if we never do a microversion bump for 500->4xx do we get closer to what we need? thats the stuff thats worth backporting (often)
14:24:34 <jaypipes> mriedem: that is correct. you cannot backport API-changing bug fixes. period. but a 500 -> 403 is not an API-changing bug fix (it's considered correcting wrong behaviour)
14:24:47 <mriedem> jaypipes: then our docs need to be updated
14:24:51 <mriedem> i can push that change
14:24:52 <jaypipes> yes, they do.
14:24:58 <mriedem> specifically http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n68
14:24:58 <jaypipes> mriedem: I will review accordingly
14:25:09 <mriedem> at least needs to say * except for 500+ -> 400+
14:25:14 <jaypipes> ++
14:25:25 <mriedem> now the other question is http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63
14:25:42 <alex_xu> even we backport...we still can't ensure all the deployement update to that fix...
14:25:43 <mriedem> because in this one overquota case, the api is expecting 400 and 404 today, but we need to add 403 to that list
14:26:04 <mriedem> alex_xu: johnthetubaguy: i think we should table the backport thing for now,
14:26:10 <mriedem> it's not something someone wants to do *today*
14:26:20 <johnthetubaguy> mriedem: yeah, sorry, I got carried away there
14:26:25 <edleafe> mriedem: what about 500+ -> anything else?
14:26:40 * dansmith agrees with jaypipes' statement on backports
14:26:43 <jaypipes> mriedem: you may want to add some text to the effect of "under no circumstances should the API microversion ever 'fork' to use a tertiary ".Z" number. this means under no circumstances should a patch that cotnains a microversion bump be backported to a stable branch."
14:26:46 <edleafe> mriedem: i.e., it should have worked, but the bug threw a 500
14:26:48 <johnthetubaguy> edleafe: true, success is also a valid outome
14:26:55 <dansmith> jaypipes: +1
14:27:12 <edleafe> jaypipes: +1
14:27:20 <mriedem> edleafe: i'm not following,
14:27:27 <mriedem> there are like 5 use cases going here right now
14:27:34 <mriedem> and then dansmith showed up :)
14:27:38 <jaypipes> mriedem: but worded in Mortimer's phrasing, if you wish...
14:27:44 <edleafe> well, there's the problem
14:27:49 <mriedem> that asshole pissed all over the wood floors last night, so f him
14:27:55 <jaypipes> lol
14:28:01 <dansmith> hah
14:28:18 <mriedem> jaypipes: so the .Z note would be a separate patch
14:28:33 <mriedem> when we cover backport rules
14:28:49 <mriedem> anyway, let's start small with the 500->existing 400 case
14:28:56 <mriedem> i still don't like http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63
14:29:12 <mriedem> if you have 400,404 but need to add 403
14:29:26 <edleafe> mriedem: my point is that a 500 is always a bug. Fixing the bug may result in a 200 being returned, and that's OK
14:29:33 <mriedem> edleafe: yes
14:29:37 <johnthetubaguy> edleafe: +1 on that
14:29:44 <mriedem> we shoudln't require a new versoin of nova just to make shit not suck
14:29:52 <edleafe> mriedem: +1
14:29:52 <johnthetubaguy> agreed
14:29:58 <edleafe> mriedem: put that in devref, please
14:30:01 <mriedem> i'm glad we all agree on sanity
14:30:07 <mriedem> to some degree
14:30:20 <johnthetubaguy> so I think we just created a whole heap of stuff that can be backported
14:30:30 <mriedem> anyway, we can move on , i can harass jaypipes in -nova later
14:30:38 <mriedem> i still have gripe #2
14:30:51 <alaski> mriedem: on new error codes my opinion is that adding a new one shouldn't need a bump, but changing one should.  so 404->403 would, but not just adding 403 for a new thing
14:30:53 <johnthetubaguy> mriedem: the extra error codes requiring a bump?
14:31:05 <mriedem> alaski: +1 from me on that
14:31:13 <mriedem> johnthetubaguy: no, lxc ci
14:31:22 <johnthetubaguy> mriedem: ah, right, good point
14:31:26 <mriedem> lxc ci, wtf
14:31:53 <johnthetubaguy> yeah, I replied to that, mostly with oops we didn't follow through with that
14:31:54 <dansmith> no gd?
14:32:00 <mriedem> gd lxc ci wtf
14:32:09 <jaypipes> lol
14:32:14 <dansmith> ikr?
14:32:18 <mriedem> so the good news is we should be able to run it on community infra, no third party ci
14:32:19 * johnthetubaguy applies babel fish
14:32:25 <mriedem> i don't know if devstack is setup for lxc right now though
14:32:48 <mriedem> but if it does, it seems pretty straight-forward to start a job that runs a devstack in lxc config mode
14:33:00 <mriedem> and then we can wittle down the tests that won't work
14:33:04 <johnthetubaguy> mriedem: +1 it totally seems worth adding, and well, needed
14:33:10 <mriedem> having said that,
14:33:14 <mriedem> i've never used lxc
14:33:25 <johnthetubaguy> so I have reached out to the folks who claimed they wanted to help with this
14:33:37 * dansmith signs out
14:33:40 <mriedem> do we have names? s1rp, apmelton ?
14:33:43 <johnthetubaguy> in the hope they could help with the heavy lifting on that
14:33:48 <johnthetubaguy> yeah, apmelton
14:33:59 <alaski> I just forwarded the thread to apmelton
14:34:01 <mriedem> if someone could just say, this is what yo uneed in localrc for devstack,
14:34:10 <mriedem> then i think i can help with the project-config job stuff
14:34:29 <dims> mriedem: needs some additional stuff installed i think (on the base image)
14:34:37 <mriedem> dims: yeah maybe
14:34:42 <johnthetubaguy> #help can folks help mriedem with getting devstack and LXC working nicely
14:34:44 <mriedem> that's why i'm wondering if devstack is up to snuff already
14:35:01 <edleafe> not to confuse things more, but there's also LXD: http://www.ubuntu.com/cloud/tools/lxd
14:35:09 <mriedem> we don't support lxd do we?
14:35:11 <johnthetubaguy> edleafe: not sure we support that yet though
14:35:18 <mriedem> yeah, f it
14:35:28 <johnthetubaguy> its out of tree, possibly
14:35:35 <mriedem> oh yeah i think it is
14:35:35 <johnthetubaguy> but yeah, ignore that for now
14:35:38 <edleafe> ok, just thought it might handle some of the lifting for ci
14:35:44 <mriedem> https://github.com/lxc/nova-compute-lxd
14:35:45 <mriedem> bam
14:35:49 <johnthetubaguy> yeah
14:35:52 <mriedem> i remember finding that at YVR
14:35:53 <apmelton> o/
14:36:05 <johnthetubaguy> apmelton: so wondering if you can help with LCX ci?
14:36:07 <mriedem> apmelton: do you know if devstack works with lxc today, or needs work?
14:36:20 <apmelton> mriedem: it has issues
14:36:26 <mriedem> apmelton: fixable issues?
14:36:54 <apmelton> mriedem: the biggest issue is the driver is leaking ndb devices all over the place
14:37:00 <mriedem> or like, you need to build packages from source that aren't in 14.04 issues?
14:37:11 <mriedem> apmelton: but that's a bug in the driver right?
14:37:19 <mriedem> not getting devstack setup to just run it
14:37:19 <apmelton> mriedem: it seems so
14:37:32 <mriedem> i just want a job that runs the damn thing, then we iterate on fixing bugs
14:37:35 <apmelton> libvirt-lxc itself in 14.04 appeared to work just fine
14:37:47 <mriedem> right now we're blind
14:37:54 <apmelton> I totally agree
14:38:07 <mriedem> apmelton: can you get me the localrc for devstack + lxc later?
14:38:14 <apmelton> sure
14:38:17 <mriedem> sweet
14:38:20 <johnthetubaguy> sweet
14:38:21 <mriedem> ok, i'm done with items
14:38:27 <johnthetubaguy> they were good items
14:38:29 <johnthetubaguy> thanks for those
14:38:40 <mriedem> \o/
14:38:43 <johnthetubaguy> any more for any more?
14:38:57 * johnthetubaguy waits for tumble weed
14:39:27 <johnthetubaguy> cool, so lets get 20 mins back, for some extra reviewing time :)
14:39:30 <johnthetubaguy> thanks all
14:39:35 <johnthetubaguy> #endmeeting