| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-09-07 | |||
| 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 | tkajinam | oh nice | |
| 16:17:10 | gibi | niiice | |
| 16:17:10 | antia | I took the chance to submit those | |
| 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 | on topic from gibi | |
| 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: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 | |
| 16:32:30 | bauzas | and we don't have a Migration object when evacuating ? | |
| 16:32:42 | bauzas | because we could look at it | |
| 16:32:51 | gibi | we have but we can have multiple unfinished migration object with type evac | |
| 16:33:06 | gibi | having a migration object does not mean the action of that migration can progress | |
| 16:33:18 | bauzas | hmmmm | |
| 16:33:21 | gibi | maybe the dest or the source of the migration is dead and you want to evac :) | |
| 16:33:53 | gibi | so a perfect solution is impossible I think | |
| 16:33:58 | gibi | we need to compromise some requirements | |
| 16:34:15 | tkajinam | the most safe approach might be add new api microversion to require task_state=None and require operators to do reset-state | |
| 16:34:21 | tkajinam | though I know that's not something operators may like | |
| 16:34:45 | gibi | I will never ask an operator in our do to do a reset-state | |
| 16:34:58 | gibi | that is like asking for a bigger problem because you had a small one :) | |
| 16:35:19 | gibi | s/in our do/ in our doc/ | |
| 16:35:33 | tkajinam | hmm ok. I agree | |
| 16:36:01 | gibi | I mean I spent so many time in customer cases where the deployer used reset-state and created a big mess | |