14:00:21 <mriedem> #startmeeting nova
14:00:21 <openstack> Meeting started Thu Jan 25 14:00:21 2018 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <openstack> The meeting name has been set to 'nova'
14:00:36 <edmondsw> o/
14:00:38 <mriedem> almost forgot the command to start this
14:00:41 <stephenfin> o/
14:00:42 <takashin> o/
14:00:48 <edleafe> \o
14:00:54 <gibi_> o/
14:01:04 <efried> @/
14:01:10 <tssurya> o/
14:01:48 <mriedem> ok let's get started
14:01:52 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:01:57 <mriedem> #topic release news
14:02:04 <mriedem> #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule
14:02:12 <mriedem> #info osc-placement 1.0.0 released which supports up to the placement 1.2 microversion
14:02:22 <mriedem> #info Jan 25 (today!): q-3 milestone, Feature Freeze, final python-novaclient release, requirements freeze, Soft String Freeze
14:02:33 <efried> So question here.
14:02:34 <mriedem> i'll be putting up the final novaclient release after the meeting
14:02:39 <mriedem> shoot
14:02:57 <efried> How long do +W'd patches get to sit in the gate after FF before we have to shut 'em down for Q?
14:03:18 <efried> Because a week is a very realistic possibility.
14:03:30 <mriedem> 4 days and 5 hours after the last +W was applied
14:03:49 <mriedem> idk - depends on the risk of the patch i suppose and how close we are to RC1
14:03:52 <mriedem> we're 2 weeks to RC1
14:04:07 <mriedem> i think a recheck grind through next week is OK for things approved today,
14:04:16 <mriedem> anything under a week to RC1 is not OK anymore probably
14:04:32 <efried> Thanks
14:04:33 * alex_xu waves late
14:04:39 <mriedem> #info Blueprints: 52 targeted, 52 approved, 28 complete
14:04:48 <mriedem> #link Queens blueprint status: https://etherpad.openstack.org/p/nova-queens-blueprint-status
14:05:02 <mriedem> in ^ i broke out the already approved stuff, which i've been rechecking
14:05:16 <mriedem> #link Queens RC1 TODOs: https://etherpad.openstack.org/p/nova-queens-release-candidate-todo
14:05:26 <mriedem> i've been slowing adding some things to ^
14:05:28 <mriedem> as reminders
14:05:46 <mriedem> also mentioned the idea of bumping the major rpc api versions with dansmith yesterday, something we haven't done in a long time,
14:05:52 <mriedem> but would be nice to do to flush some old compat code out
14:06:13 <mriedem> any questions about the release?
14:06:28 <mriedem> #topic bugs
14:06:37 <mriedem> nothing marked critical
14:06:44 <mriedem> #info 51 new untriaged bugs
14:07:04 <mriedem> so if you're waiting and watching your stuff sit in the gate queue for 10 hours,
14:07:19 <mriedem> you can (1) help review some other stuff not yet approved, or (2) help with bug triage https://goo.gl/sweGJc
14:07:47 <mriedem> gate status has been not great as most people know
14:08:03 <mriedem> there was a big regression introduced on tuesday, http://status.openstack.org/elastic-recheck/#1745168
14:08:09 <mriedem> but the fix for that was promoted and landed yesterday
14:08:17 <mriedem> otherwise i'm just seeing really long queue wait times,
14:08:20 <mriedem> job timeouts, etc
14:08:34 <efried> Rash of POST_FAILUREs just seems to have cropped up in the last few minutes.
14:08:39 <mriedem> yeah i saw those too
14:08:48 <mriedem> i wouldn't be surprised if there is a zuul restart at some point,
14:08:58 <mriedem> which would mean re-queueing everything
14:09:19 <efried> Anecdotal observation (no real evidence): If a patch in a tall series is in the gate and you recheck stuff *above* it (which shouldn't have an effect), the gate job stops.
14:09:20 <mriedem> i also suggested to gibi that we should bump the nova functional job timeout b/c those have been timing out a lot since kernels are getting patched and nodes are slowing down
14:09:39 <mriedem> efried: have you asked infra about that?
14:09:45 <efried> No, just noticed it a few minutes ago.
14:09:52 <efried> but you bet I will.
14:10:00 <mriedem> also, on job timeout changes, neutron bumped their unit / functional test timeouts recently too
14:10:08 <mriedem> so it's not just us
14:10:19 <mriedem> ok 3rd party CI - i don't have any news here
14:10:25 <mriedem> #topic reminders
14:10:30 <mriedem> #link Rocky PTL nominations open up Jan 29 (next week): https://governance.openstack.org/election/
14:10:45 <mriedem> let me know if anyone has any questions or doubts about ^
14:10:51 <mriedem> #link Rocky Summit call for presentations is open until Feb 8: https://www.openstack.org/summit/vancouver-2018/call-for-presentations/
14:11:07 <mriedem> seems like the call for presentations comes earlier every time
14:11:15 <mriedem> #link Rocky PTG topics: https://etherpad.openstack.org/p/nova-ptg-rocky
14:11:30 <mriedem> #topic stable branch status
14:11:33 <mriedem> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
14:11:50 <mriedem> i haven't looked at what's up for review in stable in a few weeks,
14:12:04 <mriedem> but should probably do a series of stable branch releases next week
14:12:13 <mriedem> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:12:25 <mriedem> #link stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z
14:12:34 <mriedem> #info Newton 14.1.0 released; should be EOL any day now, so treat it as such
14:12:46 <mriedem> #topic subteam highlights
14:12:56 <mriedem> dansmith: awake for cells v2?
14:13:20 <mriedem> most of the meeting we spent talking about some of the issues cern is running into with moving to cells v2
14:13:25 <mriedem> they are moving to ocata now,
14:13:32 <mriedem> and plan to upgrade to pike by end of february
14:13:52 <mriedem> they'll be using one massive single cell in ocata, and then in pike start doing 1:1 cell mappings for their cellsv1 child cells,
14:14:13 <mriedem> and we talked quite a bit about stopgap solutions for what happens if a cell is down,
14:14:35 <mriedem> and to continue being able to list/show servers out of the API when the cell is down, and how to handle quotas if a cell is down
14:14:52 <mriedem> some of that is summarized in the ptg topics etherpad https://etherpad.openstack.org/p/nova-ptg-rocky
14:15:02 <mriedem> tssurya has opened a few bugs for tracking some things with nova-manage CLIs
14:15:11 <mriedem> and has promised to talk to us more often
14:15:14 <mriedem> :)
14:15:18 <tssurya> :)
14:15:26 <mriedem> ok, edleafe - scheduler?
14:15:32 <edleafe> ProviderTree series: many lower patches in the series have merged; currently https://review.openstack.org/#/c/526541/ is the beginning of the unmerged. It has a +W, but needs a recheck due to timeout error on PowerKVM.
14:15:36 <edleafe> Nested Resource Provider selection by traits series, starting with https://review.openstack.org/#/c/531899/: needs some love to fix broken future tests. Slow progress on this series.
14:15:41 <edleafe> Suppport traits for allocation_candidates, starting with https://review.openstack.org/#/c/535642/: mostly complete, just some CI indigestion issues.
14:15:43 <edleafe> Granular requests: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/granular-resource-requests. Still very much a WIP, not targeted for Queens
14:15:48 <edleafe> Remove microversion fallback code: https://review.openstack.org/#/c/528794/. Looks good, although Zuul seems to disagree.
14:15:51 <edleafe> Use alternate_hosts for resize: https://review.openstack.org/#/c/526436/. Complete with +W, but Zuul doesn't like this one either.
14:15:59 <edleafe> That's it. Zuul seems to be the biggest blocker at the moment, but rechecking is underway
14:16:48 <mriedem> ok, just a note that you don't need to recheck in general if a 3rd party CI fails
14:16:59 <mriedem> since that will send it back through zuul and you might fail something, or timeout
14:17:07 <mriedem> just recheck the 3rd party ci job
14:17:18 <stephenfin> Didn't there used to be a way to recheck specific CIs?
14:17:21 <stephenfin> ah
14:17:23 <mriedem> there still is
14:17:27 <efried> 3rd party ones, yeah
14:17:30 <mriedem> the CI should leave a comment on the patch about how to recheck just it
14:17:52 <mriedem> otherwise i go here https://wiki.openstack.org/wiki/ThirdPartySystems
14:18:01 <mriedem> find the job and see the details which should tell you how to recheck it,
14:18:06 <mriedem> if it's not there, yell at me
14:18:11 <mriedem> and i'll yell at someone else
14:18:13 <mriedem> probably my cat
14:18:31 <mriedem> alex_xu: api highlights?
14:18:36 <stephenfin> As if it would care anyway...
14:18:39 <alex_xu> we don't have api meeting this week
14:19:00 <mriedem> alex_xu: ok, anything in particular you want to mention?
14:19:16 <alex_xu> mriedem: nothing special
14:19:34 <mriedem> ok
14:19:39 <mriedem> gibi_: notification highlights?
14:19:49 <gibi_> sure
14:19:56 <gibi_> We agreed not to try to merge a fix for the problem reported in  https://bugs.launchpad.net/nova/+bug/1739325 without figuring out how that situation could happen in the first place.
14:19:57 <openstack> Launchpad bug 1739325 in OpenStack Compute (nova) "Server operations fail to complete with versioned notifications if payload contains unset non-nullable fields" [Medium,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
14:20:12 <gibi_> so this bug remains open
14:20:36 <gibi_> and Fix for https://bugs.launchpad.net/nova/+bug/1742962 is on the gate and I'm in the process of reviewing ou
14:20:36 <openstack> Launchpad bug 1742962 in OpenStack Compute (nova) "nova functional test does not triggered on notification sample only changes" [High,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
14:20:39 <gibi_> r other jobs in project-config to see if we made the same mistakes in other cases.
14:20:50 <gibi_> I'm in the process of reviewing ou
14:20:50 <gibi_> r other jobs in project-config to see if we made the same mistakes in other cases.
14:21:05 <gibi_> that is all
14:21:08 <mriedem> i'll have to check on the status of the backports for that one
14:21:30 <gibi_> mriedem: yes, and after the backports merges we have to merge the removal from project-config
14:22:01 <mriedem> ok cinder updates
14:22:06 <mriedem> #info Volume multiattach support is merged in nova with microversion 2.60, see release notes for details
14:22:13 <mriedem> #link Tracking multiattach issues and TODOs here: https://etherpad.openstack.org/p/multi-attach-volume-queens
14:22:43 <mriedem> i'd appreciate review on the nova-multiattach job patch https://review.openstack.org/#/c/532689/
14:22:44 <mriedem> in nova
14:23:11 <mriedem> it's top of a series of devstack and tempest changes so that we have a dedicated CI job for multiattach, which has to run w/o the pike UCA, so it's a bit special
14:23:46 <mriedem> i've pushed a corresponding patch to cinder to run the job there as well,
14:23:59 <mriedem> and need to do the same for devstack and tempest, which is i think why gmann was -1 on it for now
14:24:32 <mriedem> #topic stuck reviews
14:24:38 <mriedem> nothing on the agenda
14:24:56 <mriedem> i know there are several changes that are going to get deferred to rocky, and have been around for a few releases,
14:25:17 <mriedem> i put something in the ptg etherpad about how we can maybe front-load those in rocky for early review to flush the backlog before adding new stuff,
14:25:34 <mriedem> we've talked about that in the past (slots/runways/kanban) but i'm not sure what we'll do,
14:25:53 <mriedem> i think it was newton or ocata where we said no new spec approvals for the first few weeks, only re-approvals,
14:25:55 <mriedem> something like that
14:26:09 <efried> Fact is, some of the deferred stuff is probably lower priority, so not sure that makes a whole lot of sense.
14:26:11 <mriedem> but that doesn't get eyeballs on the actual re-approved code, which is the problem
14:26:14 <mgoddard> ironic node traits patches are complete but lacking on reviews. The ironic API & client have just landed in time
14:26:16 <mgoddard> https://review.openstack.org/#/q/topic:bp/ironic-driver-traits+(status:open+OR+status:merged)
14:26:17 <mgoddard> I realised it's incredibly close to freeze
14:26:21 <mriedem> efried: they are,
14:26:25 <mriedem> but we also add new low priority stuff
14:26:39 <efried> I.e. given dev & reviewer bandwidth, might make more sense to not even re-approve certain carryovers right now.
14:26:44 <mriedem> so my point is, all things being equal wrt low priority things, we should prioritize the stuff that's been around longer
14:26:59 <efried> okay, all things being equal, sure.
14:27:15 <mriedem> re-approvals are much easier than reviewing a new spec for a new low priority thing
14:27:22 <mriedem> since we've already invested the time in agreeing to do it
14:27:30 <mriedem> and the contributor has been rebasing the code for at least 6 months
14:27:40 <efried> mm, there's that :)
14:27:55 <mriedem> anyway, it's on the ptg agenda
14:28:49 <mriedem> mgoddard: given the state of the gate and how late those came along, well into q-3, i think that's probably going to get deferred
14:29:36 <mriedem> #topic open discussion
14:29:41 <mriedem> there is nothing on the agenda
14:29:48 <mriedem> does anyone have something to mention here?
14:29:59 <mdbooth> I was going to bring up mriedem 's comment here: https://review.openstack.org/#/c/523958/
14:30:11 <mdbooth> Might be more of a PTG topic, though
14:30:14 <mgoddard_> mriedem: yeah I guessed as much. TBH we weren't expecting the ironic client to land in time, so didn't push the nova side too hard. BTW those comments were meant for the scheduler update but had some huge lag on my IRC client
14:30:35 <kashyap> mriedem: Yeah, I also noted my POV there, FWIW
14:30:52 <mriedem> is there something you guys wanted to say here, or should we end the meeting?
14:31:00 <mdbooth> Although it's a topic unique to Red Hat, so we might get to agree on it all by ourselves :)
14:31:15 <mriedem> given dansmith and melwitt aren't around yet (it's early for them) it's probably not a good time to talk about that right now
14:31:19 <kashyap> mriedem: Your choice, thought I'd give you some time to read it, and not breathe down your neck :-)
14:31:30 <kashyap> Okido, no rush
14:31:31 <maciejjozefczyk> hmm, If you have a minute or two to look at https://review.openstack.org/#/c/532924/ would be gr8
14:31:54 <mriedem> maciejjozefczyk: i want bauzas to take a look at that
14:32:11 <mriedem> feel free to badger bauzas
14:32:29 <Roamer`> maybe I could just annoy everyone once again by mentioning 140733 - the thing is, Canonical has a customer who insists on using StorPool and Canonical would much prefer if the driver made it into an official OpenStack release before backporting it there... and I'd like to thank mriedem once again, and also stephenfin for agreeing to look at it
14:32:34 <Roamer`> and, again, I'll shut up now
14:32:37 <maciejjozefczyk> mriedem: Yea, I ping'ed him also
14:32:52 <mriedem> alright i think we're done here
14:32:56 <mriedem> thanks everyone, happy rechecking
14:32:57 <mriedem> #endmeeting