Earlier  
Posted Nick Remark
#openstack-nova - 2023-02-28
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: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 elodilles (non-EM branches)
16:07:37 dansmith ah, right
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 gibi then modify the upgrade doc to state that in Antelope we support N-2 (Zed) computes as best effort
16:23:48 bauzas but looks like dansmith prefers to support Zed computes with Bobcat so meh
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

Earlier   Later