21:00:06 <mriedem> #startmeeting nova
21:00:07 <openstack> Meeting started Thu Oct 12 21:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:10 <openstack> The meeting name has been set to 'nova'
21:00:26 <mriedem> who's around?
21:00:32 <melwitt> 0/
21:00:34 <dansmith> I'm pretty round
21:00:40 <takashin> o/
21:00:41 <tssurya_> o/
21:00:41 <melwitt> hah
21:00:49 <edleafe> \o
21:00:54 <mriedem> so today melwitt has the tall head and tssurya has the normal sized head?
21:01:03 <tssurya_> hehe
21:01:08 <melwitt> yeah, I liked the tall head idea
21:01:13 <efried> \o
21:01:34 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
21:01:39 <mriedem> #topic release news
21:01:44 <mriedem> #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule
21:01:51 <mriedem> #info Oct 19: q-1 milestone, nova spec freeze (1 week away)
21:02:08 <mriedem> i went through a few specs today, there are a lot out there with -1s on them
21:02:16 <mriedem> #info Blueprints: 53 targeted, 27 approved, 1 complete
21:02:25 <mriedem> #link forum topics are being reviewed: http://forumtopics.openstack.org/
21:02:37 <mriedem> there is some actual movement on the forum sessions now
21:02:50 <mriedem> any questions about the release?
21:03:03 <mriedem> #topic bugs
21:03:13 <mriedem> nothing marked as critical
21:03:17 <mriedem> #info 11 new untriaged bugs (up 5 from last week)
21:03:26 <mriedem> gate status is....
21:03:29 <mriedem> well patches are merging
21:03:30 <mriedem> so that's good
21:03:43 <mriedem> 3rd party ci - zkvm ci was having some issues,
21:03:50 <melwitt> gate on stable branches seems faily
21:03:59 <edleafe> should we be pushing new patches? Or hold off for now?
21:04:05 <mriedem> andreas is going to adjust the whitelist for the zkvm ci to see if that helps
21:04:17 <mriedem> i think we can be pushing patches
21:04:32 <edleafe> ah, ok. I was holding on to mine
21:04:39 <mriedem> melwitt: i've seen some in stable/pike merge today
21:04:45 <mriedem> got one in the gate right now
21:04:58 <melwitt> guess it just hates my patches then
21:05:24 <dansmith> gate is pretty faily now across the board no?
21:05:29 <dansmith> with logs.o.o failures and such
21:05:32 * efried has been mercilessly rechecking everything
21:05:36 <dansmith> lots of POST_FAILUREs
21:05:45 <dansmith> the stuff holding up the v3 transition
21:05:46 <melwitt> I've seen lots of stuff merging on master. but yeah I've seen some POST_FAILURE too
21:05:47 <mriedem> there were 2 known things that were notified out earlier today
21:05:55 <mriedem> the post failures and another one with a package dependency
21:06:06 <dansmith> melwitt: yeah the tings I've seen on master have been running fewer tests, more likely to sail through
21:06:10 <dansmith> but yeah, some is merging for sure
21:06:10 <mriedem> "Job log uploads are failing due to lack of inodes. Jobs also fail due to mismatches in gnutls packages. Workarounds for both in progress with proper fixes to follow."
21:06:32 <mriedem> that was 6 hours ago
21:06:41 <mriedem> moving on
21:06:46 <mriedem> #topic reminders
21:07:06 <mriedem> just review and reply to feedback on specs
21:07:18 <mriedem> but we're probably nearing our limit
21:07:25 <mriedem> #topic stable branch status
21:07:32 <mriedem> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
21:07:37 <mriedem> #link Etherpad for bugs tracked for Pike backports: https://etherpad.openstack.org/p/nova-pike-bug-fix-backports
21:07:47 <mriedem> i've been harassing some stable cores to review some stuff for pike so we can do a release
21:07:53 <mriedem> once some of that flushes out i'll cut a release
21:08:02 <mriedem> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
21:08:12 <mriedem> #link stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z
21:08:17 <mriedem> #info Oct 18 : stable/newton branches get tagged EOL
21:08:22 <mriedem> so less than a week to newton EOL
21:08:40 <mriedem> i'll get whiny about reviews there later in the week
21:08:51 <mriedem> #topic subteam highlights
21:08:57 <mriedem> dansmith: cells?
21:09:03 <dansmith> we talked about open reviews,
21:09:16 <dansmith> and the bug that the rally team hit, which is now resolved
21:09:23 <dansmith> and the few that melwitt uncovered with her meddling
21:09:35 <dansmith> I think that was it?
21:09:42 <dansmith> oh
21:09:45 <melwitt> :)
21:09:47 <dansmith> and tssurya_'s patch
21:09:55 <dansmith> which I have now +2d, btw
21:10:02 <dansmith> now I'm done
21:10:10 <tssurya_> dansmith : thanks :)
21:10:21 <mriedem> i think i might have also said something really inspiring and groundbreaking, but can't remember now
21:10:29 <dansmith> I remember nothing like that
21:10:34 <melwitt> ouch
21:10:35 <mriedem> ...
21:10:38 * mriedem shifts eyes
21:10:47 <mriedem> edleafe: scheduler?!
21:10:52 <edleafe> Agreed to expose the root_provider_uuid in GET /resource_providers
21:10:52 <edleafe> Reviewed the progress on various patch series
21:10:52 <edleafe> Alternate hosts series ready for review
21:10:52 <edleafe> Spent the bulk of the meeting time discussing how un-cloudy we can get with nested RPs
21:11:01 <edleafe> that's it
21:11:22 <mriedem> alright
21:11:29 <mriedem> api meeting, there are some notes in here
21:11:35 <mriedem> Talking about the spec "spec for API extensions policy removal" https://review.openstack.org/#/c/508101/, there are two questions
21:11:43 <mriedem> Whether we need a deprecation cycle for the policy removal https://review.openstack.org/#/c/508101/3/specs/queens/approved/api-extensions-merge-queens.rst@61
21:12:23 <mriedem> if we can deprecate policy rules, it seems we should
21:12:27 <mriedem> handle them like config options
21:12:33 <mriedem> which is why we have policy in code now
21:12:44 <mriedem> issue the 2nd
21:12:45 <mriedem> "The spec mixed the extension cleanup and policy removal, can we  separated them into two BPs? the extension cleanup can be a specless BP."
21:13:06 <mriedem> yes extension cleanup can be a separate specless blueprint, it has already been done that way since i think ocata
21:13:25 <mriedem> notes to gmann_afk and alex_xu ^ when they are around
21:13:40 <mriedem> ok notifications meeting updates,
21:13:51 <mriedem> several things that gibi wanted to see merged are now merged, so he's happier
21:14:15 <mriedem> some of the versioned notification translation stuff has stalled because some of the people working on it are no longer around
21:14:24 <mriedem> so gibi was going to start picking up more of those stalled changes
21:14:38 <mriedem> and there was something else but i can't remember what now,
21:14:45 <mriedem> probably me saying something awe-inspiring
21:14:53 * mriedem shifts eyes
21:15:02 <mriedem> CINDER
21:15:04 <mriedem> #help need another core reviewer on the new style volume attachment live migration change https://review.openstack.org/#/c/463987/
21:15:35 <mriedem> otherwise nova changes are kind of held up waiting on cinder changes right now
21:15:40 <mriedem> i need to go back and check the status of those things
21:15:49 <mriedem> #topic stuck reviews
21:15:58 <mriedem> so efried added this
21:15:58 <mriedem> https://review.openstack.org/#/c/499826/ -- Do we need a new microversion to add a missing "link" to GET /resource_providers?
21:16:18 <mriedem> so apparently we added some links w/o a microversion in a response once,
21:16:27 <mriedem> and now efried is trying to do the same and people are saying a microversion is required
21:16:30 <mriedem> so it's stuck
21:16:56 <edleafe> generally, if you change what someone gets from an identical request, it requires a microversion
21:17:15 <efried> Yeah, there's no argument that the *letter* of the law says you need a new microversion here.
21:17:36 <efried> I'm contending that this is a perfect example of where that rule can be overlooked.
21:17:45 <efried> can and should
21:17:55 <edleafe> For a single cloud, sure. For interop, that is breaking
21:18:16 <edleafe> It's the Monty Rule
21:18:18 <edleafe> :)
21:18:42 <mriedem> well, although,
21:18:52 <mriedem> placement in this case is admin-only so also a bit special
21:19:10 <efried> Seems weird to me that adding a new key in a dict would be breaking, but I get that that decision was made for reasons.
21:19:40 <edleafe> for key in body.keys(): process(key)
21:19:43 <smcginnis> Would a client ever need to ensure that links is there? If that's the case, the only way they can have that assurance is to ask for a specific microversion.
21:19:48 <mriedem> so https://review.openstack.org/#/c/468923/1/nova/api/openstack/placement/handlers/resource_provider.py was the thing that changed the response w/o a microversion
21:21:01 <edleafe> cdent did a naughty thing there :)
21:21:13 <efried> If we decide we need a new microversion, it seems silly to have a whole one just for this; but on the other hand it would be against the usual policy to slide it into some other unrelated change (although that too was kinda done by ^)
21:21:34 <edleafe> yeah, cause microversions are expensive!
21:22:07 <efried> Sorry, not indoctrinated enough to ascertain whether that was sarcasm
21:22:21 <mriedem> it's ed so yes
21:22:22 <edleafe> definitely sarcasm
21:22:24 <mriedem> assume sarcasm
21:22:50 <mriedem> idk, i don't have a super strong opinion on this either way
21:23:08 <mriedem> make sdague decide :)
21:23:18 <edleafe> It's a bit more work, sure, but we're trying to be more disciplined with out APIs than we have in the past
21:23:32 <edleafe> (that wasn't sarcasm)
21:24:18 <mriedem> the right thing to do is microversion the change, regardless of what wasn't done correctly before,
21:24:31 <mriedem> we bump the minimum required microversion that nova needs each release already,
21:24:39 <mriedem> so eventually the minimum we're going to require is already going to contain this thing,
21:24:48 <mriedem> so long-term it's not a big deal to do it in a new microversion,
21:24:51 <mriedem> so let's just do that
21:25:17 <mriedem> efried: ok?
21:25:46 <efried> Okay.
21:26:07 <efried> Bumps that change set down on my priority list.
21:26:20 <efried> But cool.
21:26:26 <efried> Thanks for the discussion.
21:26:41 <mriedem> ok
21:27:06 <mriedem> #topic open discussion
21:27:11 <mriedem> 2 things
21:27:19 <mriedem> 1. Is anyone interested in running a project on-boarding room at the summit? http://lists.openstack.org/pipermail/openstack-dev/2017-October/123206.html
21:27:35 <dansmith> I'll volunteer to help
21:27:41 <dansmith> if someone else will do it with me
21:27:56 <melwitt> I can help
21:27:59 <edleafe> I'll help, if only to aggravate dansmith
21:28:00 <mriedem> YES
21:28:13 <dansmith> edleafe and I can do performance art arguing
21:28:31 <mriedem> #action mriedem to ask for an onboarding room at the summit, piloted by dan, mel and ed
21:28:50 <edleafe> dansmith: https://www.youtube.com/watch?v=kQFKtI6gn9Y
21:29:08 <mriedem> ok final thing
21:29:11 <mriedem> Kevin_Zheng: specless blueprint for adding more instance actions: https://blueprints.launchpad.net/nova/+spec/fill-the-gap-for-instance-action-records
21:29:16 <mriedem> we talked about this at the ptg,
21:29:37 <mriedem> and i had asked kevin to look into other server api actions that we were missing, so he found a few others to put in there
21:29:50 <mriedem> i'm ok with it as a specless blueprint, but bringing it up here for publicity
21:29:54 <mriedem> any objections?
21:30:42 <mriedem> taking that as a no
21:30:50 <mriedem> does anyone else have anything for open discussion?
21:31:25 <mriedem> ok i guess that's it
21:31:27 <mriedem> thanks everyone
21:31:29 <mriedem> #endmeeting