16:02:00 <bauzas> #startmeeting nova
16:02:00 <opendevmeet> Meeting started Tue Feb 28 16:02:00 2023 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:00 <opendevmeet> The meeting name has been set to 'nova'
16:02:06 <bauzas> sorry, bit late here
16:02:22 <Uggla> o/
16:02:30 <elodilles> o/
16:02:31 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:02:40 <bauzas> let's start
16:02:44 <bauzas> #topic Bugs (stuck/critical)
16:02:44 <dansmith> o/
16:02:50 <bauzas> #info No Critical bug
16:02:54 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 17 new untriaged bugs (+1 since the last meeting)
16:03:05 <bauzas> Uggla: any bug you wanna raise ?
16:03:11 <gibi> o/
16:03:21 * gibi might need to disappeare suddenly
16:03:23 <bauzas> if not, let's skip
16:03:28 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:41 <bauzas> sean-k-mooney: can you be the next bug baton owner ?
16:03:46 <Uggla> bauzas, no nothing special
16:03:50 <bauzas> ack
16:04:04 <sean-k-mooney> i guess so
16:04:23 <bauzas> cool ta
16:04:27 <bauzas> #info bug baton is being passed to sean-k-mooney
16:04:31 <bauzas> moving on so
16:04:36 <bauzas> #topic Gate status
16:04:41 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:04:47 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures
16:05:01 <bauzas> I'll be honest, I didn't had a lot of time to look at the failures
16:05:11 <bauzas> have you seen some CI failure ?
16:05:24 <dansmith> definitely improving
16:05:39 <bauzas> indeed
16:05:42 <dansmith> the volume detach on cleanup failures have all but gone away except for the live mgiration tests,
16:05:48 <dansmith> and I have a patch up for that right now
16:06:15 <dansmith> both of those are failures in cinder tests that have gone on for years without getting proper attention
16:06:29 <dansmith> but they've been spiking a lot lately, so hopefully this will really improve things
16:06:36 <bauzas> ok
16:06:42 <gibi> glad to hear that
16:06:58 * bauzas looks at https://zuul.openstack.org/builds?project=openstack%2Fnova&branch=master&result=FAILURE&skip=0
16:07:01 <elodilles> btw, can we expect the same for stable branches with this fix as well? (less volume detach and cleanup failures)
16:07:14 <dansmith> elodilles: the fixes were in tempest
16:07:24 <dansmith> elodilles: so that's branchless and should apply to stable right?
16:07:28 <bauzas> I don't see a lot of failures for the same job
16:07:29 <elodilles> so it means that where the tempest is not pinned
16:07:37 <dansmith> ah, right
16:07:37 <elodilles> (non-EM branches)
16:07:50 <elodilles> cool, thanks!
16:08:26 <bauzas> ok, let's then move on
16:08:53 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:08:56 <bauzas> all greens
16:09:01 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:09:05 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:09:25 <bauzas> #topic Release Planning
16:09:30 <bauzas> #link https://releases.openstack.org/antelope/schedule.html
16:09:34 <bauzas> #info Antelope-rc1 is in 0.2 weeks
16:09:40 <bauzas> (which is on Thursday)
16:09:46 <bauzas> #link https://etherpad.opendev.org/p/nova-antelope-rc-potential
16:09:49 <elodilles> even the rc1 patches are generated! ;)
16:10:00 <elodilles> * release patches
16:10:31 <bauzas> elodilles cool but we need to update at least the nova one
16:10:53 <elodilles> ack, that is expected
16:11:03 <elodilles> don't forget to signal this (if not yet done)
16:11:10 <elodilles> with a -1 on it
16:11:33 <bauzas> at least we need to merge first https://review.opendev.org/c/openstack/nova/+/874932 (min servion version), https://review.opendev.org/c/openstack/nova/+/873584 (logging revert) and https://review.opendev.org/c/openstack/nova/+/875380 (reno prelude)
16:11:41 <elodilles> (and thanks in advance o:))
16:11:58 <bauzas> elodilles: indeed, doing it now
16:12:39 <bauzas> so
16:13:20 <bauzas> about https://review.opendev.org/c/openstack/nova/+/874932 I think we are OK with how to use rolling upgrades with SLURP and non-SLURP releases
16:14:12 <bauzas> sean-k-mooney had a concern with https://review.opendev.org/c/openstack/nova/+/875380 but we'll discuss it tomorrow
16:14:45 <bauzas> anything people want to discuss with RC1 ?
16:15:22 <gibi> bauzas: will you add a reno for https://review.opendev.org/c/openstack/nova/+/874932
16:15:47 <gibi> bauzas: it now allows Antelope to support Yoga computes
16:15:53 <bauzas> gibi: I provided a new phrase in the prelude
16:15:54 <gibi> which is N-2
16:16:18 <bauzas> gibi: but like you said, we could also modify the rolling-upgrade doc
16:16:48 <gibi> yeah, my point is we either do a proper documented N-2 support, or we keep the N-1 check for now
16:16:51 <bauzas> prelude patch is https://review.opendev.org/c/openstack/nova/+/875380
16:17:03 <gibi> but right now the code patch allows N-2 while our doc says otherwises
16:17:22 <bauzas> gibi: okay, then I'll add a new change before we create the RC1
16:17:34 <gibi> in the current form I cannot +2 https://review.opendev.org/c/openstack/nova/+/874932
16:17:49 <gibi> as it is inconsistent with our doc
16:18:15 <gibi> but as I said I'm OK to move the doc to match with the code or move the code to match with the doc
16:18:16 <bauzas> gibi: so you want me to modify https://docs.openstack.org/nova/latest/admin/upgrades.html#rolling-upgrade-process ?
16:18:51 <gibi> bauzas: I would like to see a consistent documentation about Antelope supports regarding old compute service versions
16:19:13 <gibi> if we go with Antelop supporting Yoga computes then yes https://docs.openstack.org/nova/latest/admin/upgrades.html#rolling-upgrade-process needs a change
16:19:45 <gibi> (or we just fall back to only support N-1 and modify https://review.opendev.org/c/openstack/nova/+/874932 to only support Zed computes in Antelope)
16:19:56 <bauzas> cool, then I'll just add a doc modification for it in https://docs.openstack.org/nova/latest/admin/upgrades.html#rolling-upgrade-process
16:20:00 <bauzas> shit
16:20:11 <bauzas> add a doc modif in https://review.opendev.org/c/openstack/nova/+/874932
16:20:23 <gibi> OK
16:20:55 <bauzas> do people prefer here to only support Zed instead of Yoga ? https://review.opendev.org/c/openstack/nova/+/874932
16:21:00 <bauzas> dansmith: sean-k-mooney: ^
16:21:25 <dansmith> for bobcat or antelope?
16:21:51 <bauzas> MHO is that I'd prefer to modify the rolling upgrade document and say yes, we can support Yoga computes for Antelope services
16:21:55 <dansmith> as I think I've mentioned, for antelope I think it would be nice to have a best-effort trial run of N-2 support, so antelope would support yoga
16:22:04 <dansmith> yeah that ^
16:22:14 <sean-k-mooney> ya i think yoga makes sense
16:22:33 <bauzas> dansmith: yeah, gibi asked either to modify the doc or not modify it but only support Zed computes with Antelope conductors
16:22:44 <bauzas> I'd prefer the former
16:22:48 <dansmith> yeah
16:22:49 <sean-k-mooney> with that said for bobcat technially it should be antelope but i assume dansmith would prefer zed
16:23:09 <dansmith> sean-k-mooney: I'd prefer we just try to do N-2 always unless we come up with a blocking reason we can't yeah
16:23:22 <bauzas> that's another change https://review.opendev.org/c/openstack/nova/+/875621/ that needs to be merged *after* RC1
16:23:23 <dansmith> I think we'll be able to do it
16:23:35 <sean-k-mooney> right whihc is not strictly requried by the governance resolution but im ok to try that until it breaks
16:23:48 <bauzas> but looks like dansmith prefers to support Zed computes with Bobcat so meh
16:23:48 <gibi> then modify the upgrade doc to state that in Antelope we support N-2 (Zed) computes as best effort
16:23:53 <dansmith> sean-k-mooney: if nothing else, it'll highlight the thing(s) that prevent us from doing it, which are good for planning
16:24:21 <dansmith> gibi: best effort is the right terminology yeah
16:24:27 <bauzas> ok, so let's try to make the grenade-skip-level job voting
16:24:48 <dansmith> s/make/keep/ right?
16:24:56 <bauzas> it's n-v as I speak
16:25:05 <sean-k-mooney> voting based on 22.04 wiht zed ->bobcat
16:25:06 <bauzas> and only in check
16:25:08 <dansmith> oh, I thought I looked
16:25:20 <bauzas> only in check pipeline
16:25:21 <dansmith> okay, I see.. yeah "make" then
16:26:01 <bauzas> sean-k-mooney: cool then I can modify https://review.opendev.org/c/openstack/nova/+/875621/ to make grenade-skip-level *voting*
16:26:28 <bauzas> (and adding it to the gate pipeline)
16:27:06 <bauzas> that one would be merged *AFTER* 2023.1 RC1 to be clear, so it would be a 2023.2 change
16:27:17 <bauzas> agreed ?
16:27:43 <sean-k-mooney> yes
16:27:58 <bauzas> ok, and about your point with focal, sure
16:28:21 <bauzas> we need to test the N-2 rolling upgrade with ubuntu 22.04 only, right?
16:28:30 <sean-k-mooney> yes
16:28:39 <bauzas> cool
16:28:41 <sean-k-mooney> because i want us to bump our min libvirt/qemu
16:28:45 <bauzas> looks like we have consensus
16:28:51 <dansmith> I think we can only switch that once we convert it to start from zed, which it doesn't currently do
16:28:58 * bauzas can't remember when we supported Jellyfish
16:29:02 <sean-k-mooney> and i htink the  ones we chose last were released in 20.10
16:29:24 <sean-k-mooney> yes it will need to wait for changing to zed
16:29:27 <bauzas> what's the TC supported release for Yoga ?
16:29:29 <sean-k-mooney> which might need a grenade change
16:29:41 <dansmith> sean-k-mooney: it will yeah
16:29:53 <sean-k-mooney> https://github.com/openstack/governance/blob/master/reference/runtimes/yoga.rst
16:29:57 <sean-k-mooney> 20.04
16:30:19 <sean-k-mooney> its technically the same for zed 20.04
16:30:28 <sean-k-mooney> but canoncial released zed on 22.04
16:30:50 <bauzas> that's what I was looking for
16:30:51 <dansmith> I need to talk to gmann first but I will propose the skip-level job change
16:30:59 <bauzas> so
16:31:19 <sean-k-mooney> devstack works fin with zed on 22.04 the last time i tried it so i expect it to work
16:31:21 <bauzas> are we saying that we would use focal or jammy for the N-2>N skip-level job ?
16:31:35 <sean-k-mooney> focal for now jammy when we change to zed
16:31:40 <dansmith> jammy once we upgrade to zed->bobcat
16:31:43 <bauzas> cool
16:31:54 <bauzas> I agree then
16:32:24 <bauzas> #action bauzas to make our grenade-skip-level job voting after antelope rc1 on focal
16:32:39 <bauzas> I guess we're done with that topic
16:32:46 <bauzas> last point tho
16:32:54 <bauzas> #info who's interested in running for being a release liaison ?
16:32:59 <bauzas> we discussed it last week
16:33:11 <bauzas> as a reminder, https://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
16:33:48 <bauzas> tl;dr: look at Gerrit to see whether the releases team created a patch for reviews
16:33:58 <bauzas> and say yay or nay on that patch
16:34:35 <bauzas> that job is basically backed by a French person that knows it for a while
16:34:54 <bauzas> but I'd prefer not to be alone in order to avoid elodilles to hassle me with pings
16:34:56 <bauzas> :p
16:35:07 <elodilles> note: release liaisons are added as reviewers automatically (usually) to related release patches
16:35:36 <bauzas> on a side note, I have a non-urgent patch for cleaning up the PTL guide https://review.opendev.org/c/openstack/nova/+/875730
16:35:40 <sean-k-mooney> i have done it now for 2-3 releases  i can try and find time when pinged to look but if other are intereested let us know
16:35:55 <bauzas> that may help this person to know what to look and when
16:36:03 <bauzas> sean-k-mooney: we can have multiple liaisons
16:36:21 <sean-k-mooney> yep
16:36:41 <bauzas> I very briefly discuss this with Uggla and he was showing a very slight interest in that
16:36:46 <bauzas> discussed*
16:37:05 <bauzas> but maybe he left the meeting now, he had another appointment
16:37:07 <sean-k-mooney> which is a good point it does not have to be a person form the core team nessisarly
16:37:16 <auniyal> o/ I can !
16:37:21 <sean-k-mooney> we are not in rush
16:37:47 <bauzas> auniyal: ack, noted.
16:37:58 <bauzas> I'll discuss this with you later
16:38:02 <auniyal> ack
16:38:26 <bauzas> thanks for the offer
16:40:01 <bauzas> moving on
16:40:15 <bauzas> #topic vPTG Planning
16:40:23 <bauzas> the usual now reminder
16:40:25 <bauzas> #link https://www.eventbrite.com/e/project-teams-gathering-march-2023-tickets-483971570997 Register your free ticket
16:40:30 <bauzas> and
16:40:32 <bauzas> #link https://etherpad.opendev.org/p/nova-bobcat-ptg Draft PTG etherpad
16:40:40 <bauzas> the etherpad starts to grow
16:41:00 <bauzas> I haven't yet been asked how many slots we gonna want for the vPTG
16:41:11 <bauzas> be sure I'll tell you once I'm reachend
16:41:17 <bauzas> reached*
16:41:27 <bauzas> #topic Review priorities
16:41:32 <bauzas> #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
16:41:36 <bauzas> #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
16:42:43 <bauzas> #topic Stable Branches
16:42:52 <bauzas> elodilles: your time
16:42:54 <elodilles> thanks
16:43:03 <elodilles> actually, nothing special to report,
16:43:14 <elodilles> #info stable gates seem to be OK
16:43:26 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:43:44 <elodilles> use this if you see any new errors ^^^
16:43:49 <elodilles> that's all from me
16:44:12 <bauzas> all good
16:44:26 <bauzas> no news is good news
16:44:34 <bauzas> #topic Open discussion
16:44:40 <bauzas> nothing on the agenda
16:45:06 <bauzas> I guess we can call it a wrap ?
16:45:23 <auniyal> o/
16:45:29 <auniyal> There are some bugs that are either fixed but not closed for some reason or do not have much information so people can work on them (IMO), which makes our backlog big.
16:45:43 <auniyal> Os-vif:
16:45:43 <auniyal> https://bugs.launchpad.net/os-vif/+bug/1654117
16:45:43 <auniyal> https://bugs.launchpad.net/os-vif/+bug/1670628
16:45:43 <auniyal> https://bugs.launchpad.net/os-vif/+bug/1702262
16:45:43 <auniyal> fixed here: https://review.opendev.org/c/openstack/os-vif/+/479861/
16:45:47 <bauzas> that's a topic I added for the vPTG
16:46:02 <auniyal> okay
16:46:11 <bauzas> I'd like us to scrub our bug number by abandoning very old reports
16:46:21 <bauzas> but I'd prefer to discuss it at the PTG
16:46:38 <auniyal> ack bauzas
16:46:58 <bauzas> and yeah, some bug reports may not be automatically closed if the gerrit patch forgot to correctly write the commit msg tag
16:47:14 <bauzas> so the launchpad sync is not automatically done
16:48:13 <bauzas> auniyal: feel free to close the bug report with a comment
16:48:27 <bauzas> the status is then Fixed Released in LP
16:48:49 <bauzas> any other questions ?
16:48:55 <bauzas> I have to go errand in a sec
16:49:52 <bauzas> looks not
16:49:54 <bauzas> if so
16:49:56 <bauzas> thanks all
16:50:02 <bauzas> #endmeeting