16:00:05 <gibi> #startmeeting nova
16:00:06 <openstack> Meeting started Thu Jun 11 16:00:05 2020 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'nova'
16:00:15 <gibi> o/
16:00:19 <artom> o/
16:00:26 <dansmith> o/
16:01:11 <bauzas> \o
16:01:58 <gmann> o/
16:02:11 <sean-k-mooney> o/
16:02:14 <gibi> lets get started
16:02:15 <gibi> #topic Bugs (stuck/critical)
16:02:19 <gibi> no critical bug
16:02:26 <gibi> #link 22 new untriaged bugs (+2 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:47 <gibi> at some point we reached 16 new untriaged during last week
16:03:07 <gibi> so that +2 is a bit misleading
16:03:09 <gibi> :)
16:03:23 <gibi> anyhow bugtriage is always appreciated
16:03:37 <gibi> any bug we need to mention here?
16:04:25 <gibi> #topic Runways
16:04:34 <gibi> welcome to our new resident meeting topic
16:04:55 <gibi> Runway etherpad is up for Victoria #link https://etherpad.opendev.org/p/nova-runways-victoria
16:05:07 <gibi> we have 3 open runway slots
16:05:15 <gibi> There is one item in the queue: #link https://review.opendev.org/#/q/topic:bp/use-pcpu-and-vcpu-in-one-instance+status:open
16:05:34 <dansmith> so, I would like my glance store thing to be in the queue,
16:05:43 <dansmith> but I'm still working on the devstack test,
16:05:52 <dansmith> and it turns out that the glance support for testing this in devstack requires work
16:06:07 <dansmith> I've tested it locally a lot, but I'm working with them to get their stuff fixed so we can run that config
16:06:11 <gmann> dansmith: for file store it was done
16:06:22 <dansmith> gmann: I dunno what that means
16:06:55 <gibi> dansmith: if you feel that the non-tempest patches are ready then we can take those in to the queue
16:07:01 <gmann> dansmith: this one cover some flag - https://review.opendev.org/#/c/689104/
16:07:06 <sean-k-mooney> gmann: it can create multiple files stores but the image import workflow does not work.
16:07:24 <gmann> we have not added test yet i think.
16:07:45 <dansmith> gibi: yeah the nova patches are ready, IMHO
16:07:52 <dansmith> gmann: yeah that's not really related to what I'm doing
16:08:10 <dansmith> gibi: starts here: https://review.opendev.org/#/c/731550/2
16:08:22 <dansmith> it's really just two real patches in nova,
16:08:35 <gibi> dansmith: cool. lets queue them. Will you have time in the next two weeks to iterate on those patches if there is review?
16:08:49 <dansmith> then a doc patch I'm waiting for some input/help with, but that could go later at another time and then the devstack test at the end once I get it working
16:09:42 <dansmith> gibi: I'm out tomorrow but next week yes
16:09:49 <gibi> I think that works
16:10:06 <artom> All of RH is out tomorrow, FWIW
16:10:28 <dansmith> uep
16:10:33 <bauzas> already said to our Great Leader ;)
16:10:45 <gibi> are there other willing to review the dansmith patches if I put then in a runway slot?
16:10:51 <gibi> s/other/others/
16:11:07 <bauzas> I could
16:11:12 <gibi> cool
16:11:12 <bauzas> => next week tho
16:11:15 <gibi> ack
16:11:42 <bauzas> IIUC, that's the spec we merged last release ?
16:11:43 <gibi> stephenfin also confirmed that the hi will have time to iterate on the patches in use-pcpu-and-vcpu-in-one-instance next week
16:11:44 <dansmith> glance does not test the configuration we need at all,
16:12:02 <dansmith> so this will also increase coverage in that area if I can get the test working
16:12:17 <dansmith> bauzas: no, merged this release
16:12:30 <bauzas> okay, will get the context
16:13:10 <gibi> so use-pcpu-and-vcpu-in-one-instance could go in a runway slot to if there are people willing to review
16:13:56 <gibi> to be precise the first 7ish patch of that series are ready for a slot
16:14:24 <gibi> if nobody jumps on this then I will look at it next week
16:14:58 <gibi> #action gibi to put the glance multistore patches to runway slot
16:15:03 <artom> We should probably update the topic in the main channel with the correct runways link
16:15:08 <artom> It's still saying ussuri
16:15:15 <gibi> #action gibi to put use-pcpu-and-vcpu-in-one-instance to a runway slot
16:15:21 <gibi> artom: good point
16:15:56 <gibi> I'm wondering If the bot would op me to change the topic
16:16:14 <bauzas> you need +o
16:16:35 <gibi> anyhow I will check it after the meeting
16:16:56 <gibi> #action gibi to make sure that the #openstack-nova channel topic is up to date
16:17:10 <gibi> any other runway related thing to discuss?
16:17:12 <dansmith> gibi: I put it in the queue with linkes,
16:17:17 <dansmith> so you can move that to queue if/when ready
16:17:31 <gibi> dansmith: thanks!
16:18:27 <gibi> #topic Release Planning
16:18:33 <gibi> Victoria Milestone 1 is next week.
16:18:40 <gibi> We have ~5 open specs #link https://review.opendev.org/#/q/project:openstack/nova-specs+status:open
16:18:57 <gibi> Do we want / need a spec review day next week?
16:19:09 <artom> That's a *massive* drop
16:19:29 <artom> I'm trying to remember if we (RH) have anything outstanding we want to propose
16:20:01 <artom> But - brainstorming here - we could try using some of that bandwidth that's theoretically freed to work on bugs/tech debt
16:20:11 <gibi> artom: no rush, we did not do spec freeze until M2
16:20:28 <gibi> I mean we will not do spec freeze
16:20:30 <gibi> until M2
16:20:55 <dansmith> we've already merged some specs,
16:20:59 <gibi> artom: also we have a list of already approved bp
16:21:00 <dansmith> those are just the open ones right?
16:21:11 <gibi> dansmith: yes those are just the open ones
16:21:19 <artom> Fair - no point in rushing anything
16:21:29 <gibi> here are the approved bps https://blueprints.launchpad.net/nova/victoria
16:21:36 <dansmith> didn't we only merge like 15 specs of work last cycle or something? I think we're probably fine :)
16:21:51 <gibi> dansmith: we merged 20 out of 30 approved bps
16:22:04 <gibi> but some was specless
16:22:10 <dansmith> yeah I meant specs
16:22:32 <dansmith> but anyway, we're not far off in terms of approved-to-merged for where we are in the cycle
16:23:21 <gibi> yeah, we don't need lot more work to fill our bw
16:23:53 <gibi> anyhow based on the reactions I don't see the need for a spec review day next week
16:24:34 <bauzas> anyone can review
16:24:51 <gibi> sure, anyone anytime :)
16:25:12 <gibi> any other thing to discuss about the V release?
16:26:06 <gibi> #topic Stable Branches
16:26:15 <gibi> There is a stable/train release proposed https://review.opendev.org/#/c/734952
16:26:37 <gibi> Is there anything we should wait for before release the next train point release?
16:27:00 <bauzas> haven't seen the stable/train branch for a while
16:27:11 <bauzas> do we need to review some changes ?
16:27:48 <gibi> there are some open patches but also there is good content in the proposed stable/train release so I'm OK to pull the trigger on it
16:28:17 <gibi> if you have anything important that is open in stable/train then tell me and we can wait for it to land
16:28:27 <elod> there are 2 bugfix close to +W, but maybe we don't need to wait for them
16:29:29 <gibi> I don't see any objection and we can always release another stable/train. so I will +1 the release patch after the meeting
16:29:52 <elod> +1
16:29:54 <gibi> any other stable branch related topic we need to talk about?
16:30:34 <elod> i don't see such
16:31:02 <gibi> #topic Sub/related team Highlights
16:31:09 <gibi> API (gmann)
16:31:44 <gmann> nothing much to share today.  i need to update healthcheck things as per what we discussed in PTG. i think i will  next week
16:32:01 <gibi> cool thanks
16:32:06 <gibi> Libvirt (bauzas)
16:32:07 <gmann> and policy side, we have oslo spec to list all we need to do on oslo side
16:32:16 <bauzas> #link https://etherpad.opendev.org/p/nova-libvirt-subteam
16:32:21 <bauzas> nothing this week to relatez
16:32:23 <bauzas> relate*
16:33:24 <gibi> #topic Stuck Reviews
16:33:30 <gibi> nothing on the agenda
16:33:40 <gibi> does anybody has anything to raise?
16:34:22 <gibi> #topic Open discussion
16:34:31 <gibi> (bauzas): Seeking approval for specless bp #link https://blueprints.launchpad.net/nova/+spec/offline-reshape-tool
16:34:41 <bauzas> honestly, I'm torn
16:34:48 <bauzas> we discussed it at the PTG
16:34:52 <dansmith> seriously?
16:34:53 <bauzas> and I think we have a direction
16:35:03 <bauzas> but do we need a spec ?
16:35:16 <bauzas> we already have https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/reshape-provider-tree.html#offline-upgrade-script
16:35:25 <dansmith> we did, but surely seems like a spec is warranted just to codify what we discussed and briefly noted in an etherpad into a coherent plan for posterity to me
16:35:42 <dansmith> maybe it's just me
16:35:55 <bauzas> the concern from sean-k-mooney was about compute nodes not being able to call the DB because of some network
16:35:58 <artom> How we're going to do that with the virt-driver offline makes no sense to me, so I'd like to read a spec :)
16:36:39 <sean-k-mooney> bauzas: actully i was concerned that we would require db acess for the tool to work when exectued
16:36:49 <bauzas> so we would have to explain how to use the (possible) two clients
16:36:50 <dansmith> sean-k-mooney: we would have to, AFAIK
16:36:57 <gibi> bauzas: let's have a spec, and you can copy as many thing from reshape-provider-tree.html#offline-upgrade-script as you can reuse
16:37:07 <bauzas> cool, will do as it's a consensus
16:37:10 <bauzas> thanks
16:37:13 <sean-k-mooney> dansmith: well i mean copleing it so it required vs spliting into two commands
16:37:44 <dansmith> coupling?
16:38:03 <sean-k-mooney> dansmith: e.g. one command ran on the compute to figure out what to reshape and a second run with db access using the outpu of the first
16:38:10 <dansmith> meaning break the "gather data" from the "apply changes" piece like we discussed for the cross-project case I guess? yeah
16:38:13 <dansmith> ack
16:38:18 <gibi> next point (we have couple of bps on the agenda)
16:38:19 <dansmith> sounds like spec material indeed :)
16:38:26 <gibi> Seeking approval for specless bp #link https://blueprints.launchpad.net/nova/+spec/cyborg-rebuild-and-evacuate
16:38:48 <gibi> it already has the code proposed
16:38:59 <gibi> #link https://review.opendev.org/#/c/715326/
16:39:05 <dansmith> I assume this is just feature fleshing-outing, and that there's nothing major that needs to change because of cyborg?
16:39:20 <dansmith> if so, then I'm okay with that being specless since it should be straightforwardf
16:39:31 <gibi> I have the same assumption, and I agree to approve it as specless
16:39:58 <sean-k-mooney> the rebuild and evecauate is the patch i did at the end of the cycle, so it change the rpc to pass the arq uuids but that about it
16:40:04 <sean-k-mooney> the rest is pretty simple
16:40:14 <dansmith> ack
16:40:22 <gibi> I don't see any objection
16:40:32 <gibi> #action gibi to approve https://blueprints.launchpad.net/nova/+spec/cyborg-rebuild-and-evacuate
16:40:46 <sean-k-mooney> the other operations shelve,suspend and resize are similer in scope and will be propsoed sepereatly
16:40:46 <gibi> next
16:40:49 <gibi> Seeking approval for specless bp #link https://blueprints.launchpad.net/nova/+spec/cyborg-shelve-and-unshelve
16:41:03 <dansmith> ack
16:41:15 <gibi> there are WIP patches up
16:41:26 <gibi> any objection?
16:41:40 <dansmith> not from me
16:42:04 <sean-k-mooney> ya the summary is at shelve offload, delete arqs and release the device, on unshelve claim it again via new arqs like fresh spawn
16:42:19 <dansmith> oh, hmm
16:42:23 <dansmith> didn't think about that
16:42:29 <sean-k-mooney> the rest of shelve already works
16:42:42 <dansmith> if it roughly follows the same as spawn though then probably okay
16:43:23 <sean-k-mooney> ya it just does not pass the request to placemnet or claim the device on unshelve today
16:43:40 <dansmith> okay well, I'll have to look at the code,
16:43:46 <gibi> OK, don't see any objection to approve the bp
16:43:52 <dansmith> and may change my mind if it looks too hairy, but okay for the moment to be specless
16:43:55 <gibi> we can continue the discussion in the code review
16:44:00 <gibi> cool
16:44:05 <gibi> next
16:44:19 <gibi> (gibi): I will be on PTO between 27th of July and 3rd of August (and between Aug 10 - 24). 30th of July is Milestone 2 and spec freeze, so I would need a stand-in handling the freeze during that week.
16:44:57 <dansmith> can we wait until closer to that time to find a volunteer?
16:45:04 <dansmith> plans are kinda up in the air for a lot of people right now
16:45:11 <gibi> sure, I wanted to give a heads up
16:45:15 * dansmith nods
16:45:17 <gibi> cool
16:45:21 <gibi> next
16:45:28 <gibi> (stephenfin): Can we make the 'cherry-picked from' line in backports preferred instead of mandatory? They're definitely nice to have, but they incur pain for larger backports consisting of multiple patches per branch (change one patch higher up and you invalid all lower backports). Maybe use Gerrit's model (add -x for first backport since it's landed and ignore for anything older)
16:45:30 <dansmith> cripes too many things
16:45:35 <gibi> some discussion about it on IRC: #link http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-06-10.log.html#t2020-06-10T15:02:18
16:45:48 <dansmith> assuming that irc link includes my -1 vote
16:45:53 <gibi> dansmith: it does
16:46:13 <artom> Yeah, -1 from me too
16:46:25 <artom> Yeah, they're a pain, but it keeps things patient and organized
16:46:32 <dansmith> agree
16:46:48 <gibi> I also does not feel the pain for using git cherry-pick -x but I do follow the backport to N-1 when it merged to N policy
16:47:03 <bauzas> I don't see the problem we'd like to resolve ?
16:47:05 <dansmith> which this helps reinforce
16:47:13 <artom> bauzas, stephenfin's in a rush ;)
16:47:21 <dansmith> yeah basically that :)
16:47:29 <sean-k-mooney> gibi: ya the fact i dont do that is normally why my urls are wrong sometimes
16:47:46 <sean-k-mooney> i normally do all the backports up front and then have to fix it
16:48:01 <bauzas> I mean, I can type 2 letters more than usual
16:48:04 <dansmith> maybe we could have a fast8 check that verifies the hashes?
16:48:15 <bauzas> and sha1s are nice when you just git log
16:48:22 <bauzas> and not use the Gerrit API
16:48:35 <dansmith> bauzas: the concern is that stephenfin wants to backport everything to N releases as soon as the master one merges, but might have to fix things later and doesn't want to have to change the hashes
16:48:37 <gmann> true, history check are more easy
16:49:14 <dansmith> bauzas: and my thoughts are that having to correct the hashes keeps things from going too quickly and out of order
16:49:19 <bauzas> dansmith: well, I don't see how you can't do it by once
16:49:26 <dansmith> and makes the lineage discoverable at the command line
16:49:26 <bauzas> if you got merge conflicts on the first backport
16:49:57 <bauzas> you basically need to resolve your conflicts on the first stable branch before you can proceed to the next ones
16:49:57 <dansmith> bauzas: you're preaching to the choir :)
16:50:10 <gibi> hm, a precommit check that verifies that the hash is part of the newer branch could work but we have stable only patches so it would need some intelligence
16:50:27 <bauzas> honestly I think we're bikeshedding
16:50:34 <dansmith> gibi: you wouldn't have the cherry-picked-from line in those
16:50:36 <dansmith> so it would be fine
16:50:40 <bauzas> but in the absence of stephenfin, I'd propose to revisit it next week
16:50:44 <gibi> dansmith: true
16:50:44 <stephenfin> I'm here
16:50:49 <gibi> stephenfin: o/
16:50:53 <bauzas> maybe I misunderstood the concern
16:51:15 <gibi> dansmith: except when you backport a stable only to stable-1
16:51:18 <bauzas> stephenfin: cool, then explain me how you can backport at once, unless you hope getting no conflicts ?
16:51:27 <gibi> dansmith: but then the hash should be valid
16:51:31 <dansmith> gibi: right :)
16:51:42 <stephenfin> But I said what I wanted yesterday. Left it on the agenda to see if opinions from people in addition to dansmith. Sounds like there's a consensus to keep them. I tried :)
16:51:44 <dansmith> gibi: and I think all we need to do is check that the hashes are valid, not that they're on the next branch or anything like that
16:51:49 <bauzas> oh, I think he's referring to a merge patch that has a different SHA1
16:52:11 <bauzas> so you need to wait for the patch to merge in order to be sure you won't get another sha1
16:52:17 <stephenfin> nigs doing the pep8 check
16:52:30 <artom> ... "nigs" o_O
16:52:35 * dansmith googles "irish slang nigs"
16:52:36 <stephenfin> not in goals
16:52:45 <bauzas> but honestly, sha1s in git commits are good
16:52:47 <stephenfin> heh, sorry
16:52:48 <artom> With the BLM stuff going on, I was worried for a second
16:52:55 * dansmith stands back
16:53:04 <bauzas> loosing this information would require us to turn into Gerrit in order to get this information
16:53:24 <dansmith> exactly my concern
16:53:26 <stephenfin> bauzas: 'git log --grep=$CHANGE_ID'
16:53:32 <dansmith> I don't want to have to go to gerrit to find lineage
16:53:52 <sean-k-mooney> stephenfin: i always uses "nigs" more like "not it" like the opisite of "dibs"
16:53:55 <dansmith> searching by change-id gets relations but not ordering and not necessarily the same thing
16:54:09 <bauzas> stephenfin: not if the master patch is on another branch, right?
16:54:10 <stephenfin> sean-k-mooney: that was the context I was using it (not doing the hacking check)
16:54:28 <dansmith> stephenfin: so that people won't notice when you don't update them? :)
16:54:38 <stephenfin> ...
16:54:54 <dansmith> mmhmm :)
16:54:56 <stephenfin> and now I've made sure my commit IDs will always be correct
16:55:11 <bauzas> also, double-checking but I think the -x rule comes from the Stable team, and not use
16:55:12 <bauzas> us*
16:55:13 <gibi> OK I think we are done with the topics on the agenda
16:55:21 <dansmith> it does
16:55:31 <gibi> anything else to mention before we run out of time?
16:55:39 <dansmith> not from me
16:55:44 <stephenfin> narp
16:55:54 * dansmith googles "irish slang narp"
16:55:54 <stephenfin> other than /me is off tomorrow
16:55:59 <dansmith> (kidding)
16:56:14 * bauzas can't go to the shop for getting a new keg so meh
16:56:16 <gibi> I will feel alone tomorrow I guess
16:56:26 <dansmith> s/alone/productive/
16:56:28 <bauzas> gibi: write a joking bot
16:56:34 <stephenfin> dansmith: I really hope you are kidding https://www.youtube.com/watch?v=ir1sVy9JLyo
16:56:48 <gibi> OK, lets close this.
16:56:49 <dansmith> stephenfin: honest
16:57:00 <gibi> thanks for joining
16:57:03 <stephenfin> well worth a watch so ^
16:57:20 <gibi> #endmeeting