14:00:00 <efried> #startmeeting nova
14:00:01 <openstack> Meeting started Thu Oct  3 14:00:00 2019 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:04 <openstack> The meeting name has been set to 'nova'
14:00:08 <mriedem> o/
14:00:09 <takashin> o/
14:00:22 <dansmith> o/
14:00:31 <gibi> o/
14:00:39 * gibi has a parallel meeting in person
14:01:46 <artom> o/
14:02:11 <efried> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:02:26 <efried> #topic Last meeting
14:02:26 <efried> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-09-26-21.00.html
14:02:37 <efried> No actions from last meeting, anyone have old biz?
14:03:34 <efried> #topic Release News
14:03:35 <efried> RC1 is out, stable/train is forked, master is ussuri
14:03:35 <efried> #link Nova Ussuri schedule seeded https://wiki.openstack.org/wiki/Nova/Ussuri_Release_Schedule
14:03:35 <efried> Please have a look at ^ and compare to the overall ussuri schedule (linked from there) and lmk if there are mistakes etc.
14:04:27 <efried> #link Release todos: https://etherpad.openstack.org/p/nova-train-release-todo
14:04:50 <efried> https://review.opendev.org/#/c/686325/ (console docs fixup) is merged in master and cherry-picked to train, needs a stable review
14:05:06 <dansmith> shall we do reserved db migrations per usual?
14:05:10 <efried> melwitt had the original, mriedem did the cherry-pick (implicit +2 iiuc), so I think we can do it with just one.
14:05:39 <mriedem> dansmith: yeah before we forget and land a db schema change :)
14:05:44 <efried> dansmith: o, yes
14:05:44 <efried> volunteers?
14:05:50 <dansmith> I'll do it
14:06:10 <dansmith> I'm inclined to do fewer than normal, any objections?
14:06:19 <dansmith> like, five each
14:06:34 <mriedem> i think that's what we've been doing for a few years now
14:06:57 <mriedem> but yeah +1 to that
14:06:57 <dansmith> I thought we did ten last time, but okay
14:07:03 <dansmith> thanks for making me look dumb :)
14:07:38 <dansmith> mriedem: only last cycle did we do five
14:07:41 <dansmith> so hrmph.
14:07:43 <mriedem> YEARS
14:07:44 <efried> The only other RC2 candidate on the list is a SEV fixup which aspiers is still digging into
14:07:54 * dansmith smacks mriedem in the mouth
14:08:57 <efried> I think ^ is "SEV doesn't work with a certain combination of settings" which, if we don't get it into the train release, at least isn't as bad as "you thought you had SEV but you didn't" or "your host crashes".
14:09:14 <efried> aspiers: around? Any update?
14:09:25 <mriedem> doesn't work as in silently ignores the sev requirement or blows up?
14:09:36 <efried> I think "guest won't boot"
14:09:43 <efried> doesn't ignore the sev requirement - that was the first thing I asked.
14:09:44 <stephenfin> If it's the thing I'm thinking of, causes the guest OS to crash
14:09:56 <stephenfin> the IOMMU stuff?
14:10:04 <mriedem> will libvirt raise an error trying to start the guest?
14:10:11 <mriedem> or you just have a running domain that is busted?
14:10:13 <efried> (thanks dansmith)
14:10:13 <efried> #action dansmith to propose db migration placeholders
14:10:14 <stephenfin> unfortunately no
14:10:24 <stephenfin> at least not from reading aspiers' comments
14:10:27 <mriedem> great
14:10:46 <mriedem> if it doesn't make train, there should be a known issue release note and a big fat warning in the docs
14:11:14 <stephenfin> "DO NOT USE IS BROKE"
14:11:20 <stephenfin> that ought to do the trick
14:11:37 <efried> yes, good point, we should propose a patch for ^ and put it under the fix.
14:11:57 <mriedem> well,
14:12:08 <mriedem> are you going to revert that if the fix lands? reverting release notes is kind of weird.
14:12:11 <mriedem> git history wise
14:12:21 <mriedem> i'd say don't put them in the same series, make them separate alternatives
14:12:30 <efried> fair
14:12:49 <mriedem> i might even suggest putting an asterisk in the prelude next to the sev thing
14:12:59 <mriedem> like barry bonds trying to get into the hall of fame
14:13:13 <mriedem> because really,
14:13:27 * stephenfin wonders who this Barry Bonds fellow is
14:13:44 <mriedem> because if there are issues like this, e.g. combinations of things breaks the guest, what other unknowns are there?
14:14:17 <stephenfin> That's kind of true of any significant new feature though
14:14:27 <stephenfin> at least we found this corner case ahead of release
14:14:31 <efried> yeah, if we never had any bugs, what would we do with our day?
14:14:38 <mriedem> the difference is,
14:14:46 <mriedem> if you think you're getting a secure vm and it's not
14:14:55 <mriedem> meaning the potential for CVEs from using this are higher
14:14:59 <mriedem> than any other random old feature
14:15:01 <mriedem> right?
14:15:01 <efried> right, and that's not what happens
14:15:06 <mriedem> in this case...
14:15:44 <mriedem> anyway, would be cool if the sev minded people can get that fix done so it's not something we need to document as a known issue to begin with
14:15:56 <mriedem> i realize they are prioritizing backporting it to rocky...
14:16:03 <efried> Again with the caveat that I don't understand this stuff deeply, I picked up from aspiers that that (lying about SEV being on) is not a thing that can happen.
14:16:50 <efried> anyway
14:17:57 <efried> o, stephenfin just volunteered (in -nova) to
14:17:57 <efried> #action stephenfin draft the SEV bug warning patch
14:17:57 <efried> thanks stephenfin
14:18:01 <efried> moving on.
14:19:28 <efried> any other RC potential items?
14:19:35 <efried> if you think of something, update https://etherpad.openstack.org/p/nova-train-release-todo please
14:19:57 <efried> #topic Summit/PTG Planning
14:20:59 <efried> Since many will not be in Shanghai, I'm going to try to do virtual ptg discussions via email, as much ahead of the ptg as possible.
14:21:22 <efried> one such discussion:
14:21:22 <efried> Ussuri scope containment
14:21:22 <efried> #link start of thread http://lists.openstack.org/pipermail/openstack-discuss/2019-September/thread.html#9832
14:21:22 <efried> #link continued http://lists.openstack.org/pipermail/openstack-discuss/2019-October/thread.html#9835
14:21:22 <efried> #link Spec template update for "core liaison" https://review.opendev.org/#/c/685857/
14:22:25 <efried> There seems to be at least vague general not-opposition to the core liaison thing. I'm going to update the spec template patch as soon as we're done here per mriedem's catch
14:22:41 <dansmith> we have a couple merged already,
14:22:47 <efried> yes
14:22:49 <dansmith> and at least one almost ready to be merged
14:22:57 * dansmith selfishly states
14:23:07 <efried> I'd like to get those filled in
14:23:11 <dansmith> so if we merge that we'll just edit those?
14:23:16 <efried> yes
14:23:33 <mriedem> and if we can't find liaisons for already approved things we'll just un-approve them?
14:23:43 <efried> I'm going to propose those edits in the same patch with placeholders for now so I can take the optional-ness out of the checker.
14:23:50 <dansmith> and in my spec's case, I just put myself as the sponsor?
14:23:51 <efried> mriedem: that seems reasonable, yes.
14:24:06 <mriedem> dansmith: you can mark me as a sponsor if it means anything
14:24:07 <dansmith> or do you want me to try to find someone else if possible?
14:24:23 <efried> dansmith: yes, unless anyone thinks the "cores (and experienced nova devs) can be their own sponsor" thing is a bad idea
14:24:25 <dansmith> mriedem: ack, I'm happy to do whatever the desired convention is
14:24:39 <efried> sorry, dansmith that was "yes, you can sponsor yourself"
14:24:51 <dansmith> efried: it really just means that I'm owning the "I know who to poke for reviews" tenet of your hypothesis right?
14:25:11 <efried> yes, and the "I know what it means for my code to be ready for reviews"
14:25:12 <mriedem> that's my understanding
14:25:17 <efried> and other cultural arcana
14:25:18 <dansmith> roger
14:25:22 <mriedem> i retract my sponsorship offer
14:25:25 <dansmith> hah
14:25:42 <mriedem> we should have like a,
14:25:49 <dansmith> I hope there is a limit of one core sponsor per cycle, so this can be my only one
14:25:55 <mriedem> thing that says "if you're a core and approve this spec, you are a bad person if you don't review it" thing
14:25:58 <dansmith> (not really)
14:26:01 <efried> I recognize this is mostly noise for core-proposed features; it's there more for the "outsiders".
14:26:16 <dansmith> efried: I know, which is why I asked so I can set the proper example
14:26:38 <efried> ack
14:27:21 <dansmith> did you want t discuss this proposal now?
14:27:35 <dansmith> or just mention it in the realm of vPTG discussions?
14:27:52 <efried> we can discuss if there's discussion needed, or we can do that in the review, up to y'all
14:28:24 <efried> the other "scope containment" issue is more controversial.
14:29:15 <efried> First, I apologize if any of my responses have come across as belligerent or sarcastic, I'm really really trying not to do that, trying to keep everything reasonable.
14:29:49 <mriedem> i haven't taken it that way fwiw
14:30:19 <efried> I recognize my bid of 25 (now 30) and the reasoning behind it was way simplistic.
14:30:46 <dansmith> ack, it's hard for me to detach the core sponsorship thing from the throttling, but if we call it liaison per your description here, and then potentially use that in throttling then it makes sense to push forward on this regardless of the throttling
14:31:09 * dansmith said throttling a lot in that
14:31:15 <efried> note that a) it's just a first stab, please let's discuss and try to refine, but also b) I was deliberately trying to avoid delving too much into the whys and wherefores because imo those discussions can't possible end well
14:31:20 <efried> heh, dansmith and throttling
14:32:35 <mriedem> i think the sponsorship thing makes sense and has happened implicitly in some cases, e.g. me and several of brinzhang's api changes in train
14:32:58 <gibi> I'm OK with the sponsorsip thing as well as the proposed ~30is limit
14:33:28 <gibi> does the bps will be selected first come first served basis?
14:33:48 <sean-k-mooney> that is something i have been wondering
14:33:52 <gibi> I mean from those bps that are qualify
14:34:02 <dansmith> that's my primary complaint about choosing a number,
14:34:16 <dansmith> that choosing a number requires more oversight and planning than "the first 25 to apply"
14:34:18 <sean-k-mooney> it kind of punishes people that are new to nova
14:34:23 <efried> gibi: tbd, but I was thinking not.
14:34:44 <efried> I was thinking we trim at/after spec freeze
14:34:48 <dansmith> because if that's the case, then we're going to be doing accelerators and a bunch of trivial things in U :)
14:34:54 <mriedem> well, first 25 to actually get approved with a sponsor if they aren't core-driven
14:35:10 <mriedem> first served are usually things that are previously approved,
14:35:23 <mriedem> and in that respect i think it's fair for them to get a bit more priority / attention
14:35:35 <mriedem> i.e. finish the old debt before taking on new debt
14:35:44 <sean-k-mooney> do we have a sense for how many items form train we will cary over
14:35:58 <sean-k-mooney> like cyborg integration come to mind
14:36:02 <dansmith> we have two major ones already in the tree
14:36:08 <dansmith> cyborg and cross-cell-resize
14:36:08 <mriedem> the 2 big ones are cyborg and cross cell resize
14:36:08 <efried> Yeah, fwiw, when I was mulling this idea originally, I was going to propose "hard limit of $N where first dibs are previously approved, second dibs are previously proposed but not approved in train"
14:36:39 <mriedem> the blueprints for spot instances and rebuild from cell0 are candidates but i'm pretty sure cern has given up on upstreaming those
14:36:44 <mriedem> after 2-3 releases
14:36:46 <dansmith> efried: note that previously approved in a cycle where we had no core sponsorship seems unfair, so you mean "previously approved and where there's a sponsor" right?
14:36:52 * gibi wants to finish live migration, evacuate, unshelve with bandwidth
14:37:06 <mriedem> gibi: commence to spec'ing :)
14:37:14 <efried> dansmith: Right, the above was before I had the core sponsor concept in mind.
14:37:21 <sean-k-mooney> gibi: you are not the only one that whats those so i hope they happen too
14:37:31 <gibi> mriedem: sure, sure
14:37:41 <mriedem> fwiw things deferred from train are here https://blueprints.launchpad.net/nova/ussuri
14:37:51 <efried> at this point, even previously-approved should have core sponsor (which is why the already-merged ones need to be updated)
14:38:19 <mriedem> *though not all things targeted at ussuri were approved in train, maybe just discussed at length
14:38:36 <sean-k-mooney> well i thin mriedem quifies for cross cell
14:38:37 <efried> As usual, we don't auto-approve a deferred thing unless someone reproposes it
14:38:54 <mriedem> yup so spot instances takes care of itself i guess
14:38:55 <sean-k-mooney> efried: and i assume you would sponcer cyborg
14:39:10 <mriedem> maybe we should get out of the weeds and save the details for -nova
14:39:14 <efried> Several of those deferred things were non-core-ish where they just got zero action in train ("developer walked away" category)
14:40:03 <efried> Cool, I'll just bring it back to: Please let's continue discussing ways to put a concrete cap on the amount of feature work in ussuri, in a way that's simple to understand and implement.
14:40:19 <efried> #topic Stable branch status
14:40:19 <efried> #link stable/train: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/train
14:40:19 <efried> #link stable/stein: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/stein
14:40:19 <efried> #link stable/rocky: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/rocky
14:40:19 <efried> #link stable/queens: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/queens
14:40:27 <mriedem> i've got a release request up for stein,
14:40:34 <mriedem> https://review.opendev.org/#/c/686301/
14:40:43 <mriedem> need to work on some more rocky and queens reviews
14:41:03 <mriedem> though many are my backports so...
14:41:06 <mriedem> help
14:41:18 <efried> mriedem: stein release request ready to go at this point?
14:41:21 <mriedem> yes
14:41:24 <dansmith> I've been trying to suck a little less lately
14:41:26 <mriedem> updated the hash this morning
14:41:34 <mriedem> dansmith: it's appreciated
14:41:40 <efried> I see three stein patches with a +2 on them, we're good leaving those behind for now
14:41:42 <efried> ?
14:41:43 <mriedem> even if i don't say so
14:41:59 <dansmith> mriedem: wouldn't hurt to send me flowers occasionally, baby
14:41:59 <mriedem> one of those has a -1
14:42:02 <mriedem> or 2 -1s
14:42:08 <mriedem> the others are low priority
14:42:17 <efried> cool
14:42:21 <mriedem> dansmith: laura first if any :/
14:42:25 <efried> I'll review the release patch fwiw
14:42:27 * mriedem is a bad partner
14:42:29 <dansmith> yeah the +2d -1ed one is hard to filter out
14:43:05 <efried> #topic Bugs (stuck/critical)
14:43:05 <efried> No Critical bugs
14:43:05 <efried> #link 74 new untriaged bugs (+2 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:43:05 <efried> #link 3 untagged untriaged bugs (-1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
14:43:05 <efried> Any bug discussions we didn't already have?
14:43:47 <efried> #topic Gate status
14:43:47 <efried> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:43:47 <efried> #link 3rd party CI status (seems to be back in action) http://ciwatch.mmedvede.net/project?project=nova
14:43:47 <efried> seems not-too-bad
14:43:54 <mriedem> well,
14:43:55 <mriedem> http://status.openstack.org/elastic-recheck/#1844929
14:44:08 <mriedem> i have a debug patch up for that https://review.opendev.org/#/c/684118/ but am unable to recreate on that patch,
14:44:09 <efried> oo
14:44:17 <mriedem> so question is if we want to just land that
14:44:43 <mriedem> it can be answered after the meeting as well
14:46:25 <efried> will review
14:46:34 <efried> #topic Reminders
14:46:34 <efried> any?
14:46:49 <efried> #topic Sub/related team Highlights
14:46:49 <efried> Placement (cdent/tetsuro)
14:46:49 <efried> ?
14:47:02 <efried> API (gmann)
14:47:39 <efried> I'd like to point out an API patch
14:47:39 <efried> #link allow versioned discovery unauthenticated https://review.opendev.org/685181
14:48:20 <efried> I guess alex_xu (on vacation) and johnthetubaguy (?) are the most qualified to look at this, but anyone else who can give feedback, that would be good.
14:48:45 <efried> #topic Stuck Reviews
14:48:45 <efried> any?
14:49:02 <efried> #topic Review status page
14:49:02 <efried> #link http://status.openstack.org/reviews/#nova
14:49:02 <efried> Count: 457 (+2); Top score: 2091 (-444 \o/)
14:49:06 <efried> stephenfin:  was that you?
14:49:24 <stephenfin> stuck reviews?
14:49:35 <stephenfin> Yeah, probably. I killed a lot of stuck
14:49:37 <stephenfin> *stuff
14:49:43 <efried> the review status score drop
14:49:48 <efried> thanks for that
14:49:50 <stephenfin> yup
14:49:53 <stephenfin> np
14:50:07 <efried> #topic Open discussion
14:50:12 <efried> One item on the agenda:
14:50:20 <efried> #help Volunteer needed to update the contributor guide (see https://review.opendev.org/#/c/685630/
14:50:53 <stephenfin> I'll do it
14:51:04 <stephenfin> I thought bauzas has something similar at one point
14:51:18 <stephenfin> but I don't see conflicts so maybe not
14:51:23 <efried> takashin proposed the usual s/$old/$new/ patch, but it seemed like we would be better off leaving it known-stale considering how stale the surrounding content is.
14:51:30 <efried> #action stephenfin to update the contributor guide
14:51:32 <efried> thanks again stephenfin
14:51:36 <stephenfin> In case you didn't refresh, I added something to that list too of open discussion too
14:51:36 <efried> you're a champ
14:51:42 <stephenfin> aww, shucks
14:51:52 <efried> ah, thanks, no I hadn't refreshed
14:52:12 <efried> Specless BP approval
14:52:12 <efried> #link nova-net diaf blueprint https://blueprints.launchpad.net/nova/+spec/remove-nova-network-ussuri
14:52:29 <sean-k-mooney> yes?
14:52:33 <dansmith> so, do we not need core sponsorship for something like that?
14:52:40 <efried> stephenfin can sponsor self.
14:52:50 <stephenfin> specless BP too
14:52:53 <dansmith> well, what I mean is, does that count in the quota
14:52:55 <stephenfin> I mean, I can submit a spec
14:52:58 <efried> question is, if we approve the bp now, and then later decide it falls "below the line", do we get to unapprove it?
14:53:00 <dansmith> stephenfin: I know, that's why I'm asking
14:53:15 <stephenfin> but it'll just be this https://img.memecdn.com/delete-all-the-things_o_4994465.jpg
14:53:16 <mriedem> we do'nt need a spec for that, it was approved before as specless, it's mostly mechanical work,
14:53:22 <mriedem> i think it should count toward quota
14:53:27 <mriedem> it will definitely be a time sink
14:53:30 <dansmith> efried: right, because if I'm picking priority, I put that lower than some other things we might be planning inside a small envelope
14:53:41 <dansmith> mriedem: yep, that's what I'm asking about
14:54:03 <sean-k-mooney> i think its still valuable to pay down that debt
14:54:11 <mriedem> yeah i think it's still worth doing
14:54:14 <mriedem> even with the new cap
14:54:15 <dansmith> of course
14:54:29 <efried> we also don't know what all is going to be on the table on Feb 13th
14:54:33 <stephenfin> I'd like to see us doing tech debt work along with feature work
14:54:43 <stephenfin> ...and it looks like I'm not alone. phew
14:54:44 <efried> so I think we should approve it now
14:54:52 <mriedem> i'm +1 on approval
14:55:14 <artom> Which reminds me - that SRIOV live migration conversion to use resources claims that came up during NUMA LM review - what do we think, specles blueprint?
14:55:50 <sean-k-mooney> i think you and i should proably scope it and then make that determination once we have
14:55:57 <mriedem> how about we get the numa live migratoin functional test stack landed first..
14:56:24 <efried> (done, specless bp approval.)
14:56:25 <artom> mriedem, well, yes, but we were talking about U tech debt :)
14:56:26 <mriedem> i.e. finish what was started rather than starting new
14:56:34 <sean-k-mooney> yes also i would like to land the periodic tempet job first too
14:56:52 <mriedem> artom: and i'm saying don't even bring it up until the func tests are done
14:57:04 <artom> mriedem, fair enough
14:57:51 <mriedem> remember we talked about backporting those to train,
14:57:57 <mriedem> the longer that stalls the harder that backport will be,
14:58:08 <mriedem> especially with stephenfin on a func test rip up rampage for nova-net
14:58:18 <stephenfin> rm -rf *
14:58:37 <sean-k-mooney> i think we are aiming to finish the migration stuff before m1
14:58:50 <mriedem> let's end this god forsaken meeting
14:58:52 <sean-k-mooney> e.g. the fucntioal test and temepest
14:59:24 <efried> y, sounds like there's more discussion to be had, artom & sean-k-mooney continue in -nova?
14:59:26 <mriedem> sean-k-mooney: money talks and all that
14:59:48 <efried> Thanks all.
14:59:48 <efried> o/
14:59:48 <efried> #endmeeting