| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-02 | |||
| 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 | gibi | and nova-next runs nova-compute and the rest with native threading | |
| 16:35:14 | dansmith | yay | |
| 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 | dansmith | I assume these are not without risk right? | |
| 16:48:10 | lajoskatona | no worries, I think now everybody busy with the releae and later with RCs | |
| 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 | |
| 16:59:24 | gibi | bauzas: today we fail here which is probably late https://github.com/openstack/nova/blob/264e868d4931595140260c0f655a10b525be38f7/nova/virt/libvirt/migration.py#L496-L500 | |
| 16:59:33 | gibi | sorry not there | |
| 16:59:40 | gibi | that is the place of the root cause | |
| 16:59:51 | gibi | we fail at | |
| 16:59:52 | gibi | File "/usr/lib64/python3.9/site-packages/libvirt.py", line 2225, in migrateToURI3 | |
| 16:59:52 | bauzas | I'm thinking of when creating the instance | |
| 17:00:30 | gibi | bauzas: that would open a can of worms, 1) pre-existing instance with duplicated MAC 2) interface attach | |
| 17:00:37 | bauzas | if you ask for two ports, can we quick get the MAC addresses already or do we need another roundtrip ? (please, I don't want this if so) | |
| 17:00:49 | gibi | if failing early is the goal then we should fail pre-live migration | |
| 17:01:01 | bauzas | yup, then yes | |
| 17:01:14 | dansmith | well, | |
| 17:01:24 | bauzas | either in the conductor check or later in compute pre-flighyt | |
| 17:01:38 | dansmith | I think if we're going to say it's not allowed, we should prevent it at instance spawn/interface attach right? | |
| 17:01:51 | dansmith | because in this case, a user can do something that prevents an admin from live migrating an instance | |
| 17:01:57 | dansmith | which is not a cool thing to find out later | |