Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-02
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
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 bauzas I'm thinking of when creating the instance
16:59:52 gibi File "/usr/lib64/python3.9/site-packages/libvirt.py", line 2225, in migrateToURI3
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
17:02:11 bauzas then it should be when we attach a port ?
17:02:14 dansmith so if we say "not allowed" it probably needs to be enforced much earlier
17:02:41 dansmith but again, I feel like this is probably something we can/should fix (even if later) with the alias stuff like we did for disks and planned for nics
17:03:22 bauzas right
17:03:32 gibi OK, if preventing it needs a bunch of code then maybe fixing it is comparable complexity (I was on the side of doccing it)
17:03:37 dansmith the disk stuff has fallen out of my brain a bit, but seems like we could use the port uuid as the alias and then we'd be able to match up the port and interface in that code, right?
17:04:00 dansmith gibi: well, I think documenting it also documents "how to prevent your operator from moving your instance around" :)
17:04:02 gibi dansmith: right port uuid is unique in openstack, nic alias is unique in the VM
17:04:08 dansmith yeah
17:05:04 gibi OK I will summarize this discussion back to the bug
17:05:29 gibi I got enough feedback that a simple doc patch will not be enough :)
17:05:57 gibi thanks
17:06:06 dansmith sorry gibi :/
17:06:10 Uggla gibi thanks to you explaining this.
17:06:47 Uggla We are already overtime, so time to close for this week.
17:06:57 cw0306-lee[m] Hi! I have a question.
17:07:01 gibi dansmith: no worries :)
17:07:16 Uggla cw0306-lee[m] last minute question, please go ahead
17:07:53 cw0306-lee[m] I tried to fix bug and added it to etherpad proposed bugfixes, will they be reviewed in order?
17:08:55 Uggla cw0306-lee[m] we will try. There is no specific order though, really depend on prio and reviewer bandwith.
17:09:19 cw0306-lee[m] Uggla: Thank you!
17:09:21 Uggla readiness too
17:10:21 Uggla ok so now time to close, thanks for joining this meeting. Have a nice day/evening and see you next week.
17:10:29 Uggla #endmeeting
17:10:29 opendevmeet Meeting ended Mon Mar 2 17:10:29 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:10:29 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.html
17:10:29 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.txt
17:10:29 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.log.html
17:10:33 gibi thanks Uggla
17:10:36 elodilles thanks o/
17:11:05 lajoskatona o/
17:11:09 Uggla gibi thanks to you, we have one more bug triaged !
17:12:22 tkajinam gmaan, regarding that novaclient tests update, do you know any stestr magic to avoid specific tests from being executed concurrently ?

Earlier   Later