Posted	Nick	Remark
#openstack-nova - 2026-03-02
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
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.

Earlier   Later