| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-02 | |||
| 16:27:44 | Uggla | r-taketn your welcome. | |
| 16:28:13 | Uggla | #topic OpenAPI | |
| 16:28:24 | Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | |
| 16:28:31 | Uggla | #info still 0 remaining | |
| 16:28:37 | Uggla | #info This topic is closed. A big thank you to stephenfin, sean-k-mooney, gmaan and all people involved with this. | |
| 16:28:42 | Uggla | \o/ | |
| 16:29:10 | gibi | congrats | |
| 16:29:54 | Uggla | #topic Stable Branches | |
| 16:30:02 | gmaan | tkajinam: on that topic, I commented on gerrit, your change is ok for me but let's fix the test as this bug fix and we can discuss further about how better we can handle the error | |
| 16:30:03 | gmaan | https://review.opendev.org/c/openstack/nova/+/978494 | |
| 16:30:16 | elodilles | thx Uggla | |
| 16:30:37 | elodilles | #info stable gates should be in good state | |
| 16:30:46 | elodilles | #info stable/2026.1 branch cut for libraries: https://review.opendev.org/c/openstack/releases/+/978397 | |
| 16:30:55 | elodilles | thanks for the review Uggla :) | |
| 16:31:03 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:32:24 | Uggla | thx elodilles | |
| 16:32:41 | Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:34:33 | Uggla | seems fwiesel is not available so moving on. | |
| 16:34:41 | Uggla | #topic Gibi's news about eventlet removal | |
| 16:34:44 | gibi | o/ | |
| 16:35:00 | gibi | nova-compute now can run in native threading mode (default is still eventlet) | |
| 16:35:09 | bauzas | \o/ | |
| 16:35:14 | dansmith | yay | |
| 16:35:14 | gibi | and nova-next runs nova-compute and the rest with native threading | |
| 16:35:17 | Uggla | \o/ | |
| 16:35:43 | gmaan | \o/ | |
| 16:35:44 | dansmith | I apologize for being so absent on those reviews, but is there a reno asking operators to test and provide feedback? | |
| 16:35:48 | fwiesel | Uggla: Sorry. was distracted. no updates | |
| 16:36:04 | Uggla | fwiesel no worries | |
| 16:36:20 | gibi | dansmith: there is reno about the change and nova logs at startup to asking for testing first in pre-prod | |
| 16:36:39 | gibi | dansmith: we can emphesize the feedback part in the prelude | |
| 16:36:56 | Uggla | dansmith, gibi, I will try to do it in prelude and highlights | |
| 16:37:04 | dansmith | ack, sounds good.. this, probably more than any previous thing really needs some concerted feedback I think | |
| 16:37:08 | gmaan | ++ for prelude | |
| 16:37:11 | gmaan | gibi: I am changing to run graceful shutdown job in both mode (eventlet mode as periodic), so that we will have coverage for both https://review.opendev.org/c/openstack/nova/+/978292 | |
| 16:37:12 | dansmith | prelude seems like a good place | |
| 16:37:22 | gibi | gmaan: cool | |
| 16:37:27 | gibi | dansmith: I agree. | |
| 16:38:00 | gibi | we punted novncproxy to H but there is some WIP patch up already from Kamil | |
| 16:38:42 | gibi | I have a set of unit test patches that we can still land becore RC1 https://review.opendev.org/c/openstack/nova/+/970069 | |
| 16:39:17 | gibi | and I have a long list of TODOs for cleanups about executors that I will prepare patches for for early H | |
| 16:40:35 | gibi | I still plan to hold the eventlet sync this week but maybe skip some calls during the RC period | |
| 16:40:52 | gibi | just to restrat in full force once master is open of H | |
| 16:40:54 | gibi | that is it from me | |
| 16:41:09 | gibi | ohh one more thing | |
| 16:41:13 | gibi | that fwiesel is around | |
| 16:41:32 | gibi | fwiesel: could you help me debugging the vmware CI with native threading | |
| 16:41:43 | gibi | https://review.opendev.org/c/openstack/nova/+/973468 | |
| 16:41:51 | opendevreview | Doug Goldstein proposed openstack/nova master: return error about external network to the user on build failure https://review.opendev.org/c/openstack/nova/+/972601 | |
| 16:41:53 | gibi | see the comments from me in ^^ | |
| 16:42:02 | gibi | I mean in https://review.opendev.org/c/openstack/nova/+/973468 | |
| 16:42:11 | gibi | the image upload seems to be problematic | |
| 16:42:27 | gibi | but snapshot works well with the libvirt driver so this is vmware driver specific | |
| 16:42:36 | gibi | so I need your help | |
| 16:44:04 | Uggla | fwiesel ? | |
| 16:44:55 | gibi | fwiesel: it is OK if you just read back and we can discuss outside of the meeting as well | |
| 16:45:58 | Uggla | fwiesel will probably answer later, moving on to the next topic | |
| 16:46:13 | Uggla | #topic Nova using openstack sdk for neutron | |
| 16:46:43 | lajoskatona | o/ thanks | |
| 16:47:00 | lajoskatona | short feedback: no progress since last meeting | |
| 16:47:43 | lajoskatona | I plan to update the floating IP and port reated changes and clean them (the one for ports actually is red so have to work more on that I think) | |
| 16:47:50 | gmaan | what's the plan on this, are we ok to merge those in rc period or wait till H? | |
| 16:48:10 | lajoskatona | no worries, I think now everybody busy with the releae and later with RCs | |
| 16:48:10 | dansmith | I assume these are not without risk right? | |
| 16:48:28 | gmaan | yeah, there is risk | |
| 16:48:33 | Uggla | gmaan, to my mind there is no urgency. And it is more something for H | |
| 16:48:56 | lajoskatona | yes, I would wait till beginning of H to have time for testing in CI | |
| 16:49:00 | lajoskatona | +1 | |
| 16:49:06 | gmaan | k, bcz I planned to review it but missed the FF so I can start but wait for H to open for merging | |
| 16:50:16 | Uggla | lajoskatona I think we are good. | |
| 16:50:28 | Uggla | moving to next topic | |
| 16:50:33 | Uggla | #topic Bug scrubbing | |
| 16:50:43 | Uggla | #info up to 212 (-4) | |
| 16:51:08 | Uggla | I'll continue to focus on that this week. | |
| 16:51:30 | Uggla | Today because we are a bit short of time, I would like to discuss only this bug: https://bugs.launchpad.net/nova/+bug/2141325 opened by gibi. | |
| 16:51:59 | gibi | o/ | |
| 16:52:03 | gibi | so in short | |
| 16:52:23 | gibi | nova assumes during live migration prep that a single VM does not have multiple tap devs with the same MAC | |
| 16:52:36 | gibi | but neutron allows setting MAC on port objects | |
| 16:52:59 | gibi | so one can set up a VM with two ports in different neworks with the same MAC | |
| 16:53:05 | gibi | and live migration will fail | |
| 16:53:35 | gibi | question: do we want to fix it, or do we want to state that please don't try to do this | |
| 16:53:48 | dansmith | is the limitation a nova thing or a libvirt/qemu thing? | |
| 16:54:01 | gibi | on nova, how we identifies tap devs across the two XMLs | |
| 16:54:04 | dansmith | i.e. is it just us using the MAC as a primary key for mapping ports? | |
| 16:54:09 | gibi | just us | |
| 16:54:10 | dansmith | ack | |
| 16:54:21 | gibi | I rather not try to touch that XML gen code | |
| 16:54:45 | gibi | as manually managing MAC in the cloud is sort of an edge case in my head | |
| 16:55:07 | dansmith | meanin you prefer we not fix this? | |
| 16:55:21 | gibi | yepp I prefer documenting this as a known limitation | |
| 16:55:28 | bauzas | could we at least fix it by doc ? | |
| 16:55:46 | bauzas | ah too late :) | |
| 16:56:03 | dansmith | I think documenting it as a limitation now is obviously better than having it fail, | |
| 16:56:33 | dansmith | but it is also probably indicative of us using something as a PK that shouldn't be, and I also think there are probably legit reasons for doing this related to HA | |
| 16:57:23 | dansmith | IIRC, we had a todo to make the NICs identifiable by alias like the disks work I did, | |
| 16:57:29 | gibi | I tried to poke the downstream reporter about their use case doing this but so far I got nothing | |
| 16:57:31 | dansmith | which is probably what we _should_ be using instead of MAC right? | |
| 16:58:00 | bauzas | could we fail early with a good self-explaned exception ? | |
| 16:58:02 | gibi | yeah libvirt has aliases. I haven't checked if it fits to our live migration XML manipulation code to use that | |