Earlier  
Posted Nick Remark
#openstack-nova - 2026-09-07
16:03:52 Uggla #topic Bugs (stuck/critical)
16:03:57 Uggla #info No Critical bug
16:04:02 Uggla #topic Gate status
16:04:10 Uggla #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:04:20 Uggla #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:04:27 Uggla #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status
16:04:33 Uggla #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:04:41 Uggla #info Please try to provide a meaningful comment when you recheck
16:04:50 gibi o/
16:05:14 Uggla Anything new about the gate?
16:05:42 gibi I had to put the functional test stabiliziton on hold for now due to internal priorities. But we still have some unstability in the functional threading job
16:05:48 gibi and I have in flight patches to work on
16:05:53 gibi but it need to wait a bit
16:06:09 Uggla Yep I know about one on my side.
16:06:27 gibi feel free to ping me if you see a functional instability and I will help judging it if it needs a new tracker or if we already have one
16:07:22 Uggla are we good for that topic ?
16:07:49 Uggla #topic Release Planning
16:07:55 Uggla #link https://releases.openstack.org/hibiscus/schedule.html
16:08:00 Uggla #info Nova deadlines are set in the above schedule
16:08:05 Uggla #info RC1 target week.
16:09:10 Uggla I should propose the highlight patch shortly.
16:09:21 Uggla #topic Review priorities
16:09:29 Uggla #link New file for Hibiscus https://etherpad.opendev.org/p/nova-2026.2-status
16:09:38 Uggla #info Starting: https://etherpad.opendev.org/p/nova-2026.2-status#L16 interesting bugs to review.
16:09:41 bauzas ack
16:10:02 bauzas don't hesitate to ping me, I have a microtime I can use for upstream reviews :)
16:10:20 Uggla bauzas sure. Thanks!
16:10:40 Uggla #topic Stable Branches
16:10:42 bauzas (more time than the time it takes for the light in between Moon and Earth, but less than a Earth round)
16:11:13 Uggla I know elodilles is on a business trip so I don't know if he can make it.
16:12:12 Uggla seems not, so lets move on or defer it later.
16:12:16 gibi I think it is pretty late for Elod at the moment
16:12:41 Uggla yep probably.
16:12:53 Uggla #topic vmwareapi 3rd-party CI efforts Highlights
16:13:00 fwiesel Hi, no updates from my side.
16:13:02 Uggla fwiesel something you'd like to share?
16:13:14 Uggla ok thanks. Welcome back!
16:13:20 fwiesel Thanks!
16:13:29 Uggla #topic Kamil's news about eventlet removal
16:13:39 Uggla sambork, gibi something to report on that front ?
16:14:06 sambork Not much since last week, key fix: restored eager thread executor creation in service managers rather than lazily in thread_pool_factory.py (#1001572) .Meanwhile, patch 1001369 (native threading test fix) waiting for update. Separately, patch 997410 (review) was updated to use futurist.DelayingExecutor, though it will merge in next release
16:14:22 sambork eom
16:15:00 gibi nothing to add form my side. I will continue stabilizing the functional tests when I get some time
16:15:34 Uggla sambork, gibi I'll notify you about the HL patch as soon as ready, so we could iterate to report the meaningful changes.
16:16:18 Uggla skipping sdk for neutron topic as Layos is not available.
16:16:34 Uggla #topic Confidential computing, status of SNP and TDX features
16:16:42 Uggla I guess nothing new here.
16:16:52 tkajinam yeah
16:16:55 gibi yeah
16:17:01 antia https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/1003958
16:17:06 gibi oooh
16:17:10 antia I took the chance to submit those
16:17:10 gibi niiice
16:17:10 tkajinam oh nice
16:17:23 gibi antia: thanks I will check it
16:17:33 Uggla cool antia!
16:17:53 antia gibi: Thanks!
16:18:01 antia nothing else from me
16:18:28 Uggla would you guys want to maintain this topic. I think we can remove it now?
16:19:17 gibi Uggla: I'm OK to drop it
16:19:24 gibi thanks everyone :)
16:19:46 Uggla or course we can speak about it if we need in open discussion
16:20:08 tkajinam yeah I think we can remove it from the regular agenda.
16:20:22 Uggla and yes thanks for this great collaboration around those topics.
16:20:49 Uggla #topic Bug scrubbing
16:20:56 Uggla #info down to 67 (-1).
16:21:03 Uggla #link https://etherpad.opendev.org/p/nova-bug-triage-roster
16:21:08 Uggla #link https://truc.uggla.fr/ to follow the trend.
16:21:28 Uggla #info Next meeting (this week): [public] Upstream bug triage. Wednesday, Septembre 09th · 15:30 – 16:00 UTC. Video call link: meet.google.com/zjr-rxus-hzj
16:21:48 Uggla #topic Open discussion
16:22:02 Uggla (gibi): I need technical guidance what to do with https://bugs.launchpad.net/nova/+bug/2166474 (Uggla: I will describe the case on the meeting)
16:22:02 Uggla on topic from gibi
16:24:05 gibi o/
16:24:35 gibi so we have that bug, it describe a nasty race where nova allows two evacuation action to overlap on the same VM at the same time
16:24:48 gibi then today I realized that we started allowing that couple of years ago
16:24:58 gibi by allowing evacuation from a non empty task_state
16:25:03 gibi to support things like
16:25:12 gibi 1. compute with a VM dies
16:25:32 gibi 2. owner try to restart the VM, VM goes to powering_off task_state that never progresses
16:25:51 gibi 3. operator realizes that the compute is dead an wants to evacuate the VM
16:26:19 gibi to support this nova allows triggering evacuation with task_state not empty
16:26:39 gibi but task_state is our lock to avoid two operation to overlap on the same VM
16:27:25 gibi obviously I can develop a patch that allow evacuation to start only from non rebuilding* task_state
16:27:36 gibi but that only solves the currently proven overlap
16:28:01 gibi I'm a bit hesitant about all the other task states what should be allowed and what should not
16:28:12 gibi so ideas folks?
16:28:24 gibi (here or offline in the bug)
16:28:27 bauzas I see
16:28:36 bauzas took a bit of time to load the context
16:28:58 bauzas we relied on task_state for knowing whether we were having an user instance action
16:29:19 bauzas but given it was an issue if we want to evacuate, we removed the conditional
16:29:28 gibi yeah
16:29:46 bauzas but now we dunno whether a current task state is because of an user action or because an evacuation is starting, right?
16:30:53 gibi right, basically we don't know if a non empty task_state at the start of evacuation means an action that cannot progress because it is against the dead compute and therefore allowed to evacuate, or it measn an action that is progressing already on another compute for this VM like a previous evac
16:31:13 bauzas hmmm OK
16:31:18 gibi but also a previous evac can be against the dead compute
16:31:19 bauzas (thinking)
16:31:48 gibi so in theory you might want to re-try evacuation as the previous evac is not progressing as that compute died during evac
16:31:50 bauzas I guess we can't look at the VM state thn ?
16:32:26 gibi not fully mapped the states, but I think you want to be able to evac from ACTIVE, STOPPED, ERROR

Earlier   Later