Earlier  
Posted Nick Remark
#openstack-nova - 2026-04-20
16:54:41 tkajinam yeah
16:54:46 sean-k-mooney i woudl prefer to always have memfd shared=true
16:55:13 sean-k-mooney but keep "annoumus" spelled correctly for those that want to opt out
16:55:27 sean-k-mooney i.e. evnetually memfd i think shoudl become the default
16:55:38 sean-k-mooney but ya in newer qemu memfd does not need numa
16:55:44 sean-k-mooney but it did when it was first done
16:57:24 sean-k-mooney the fact that memfd does not require numa affinity is one of the reaosn its intersting
17:01:25 tkajinam but not requiring numa is valid only when you don't need numa aware things, right ?
17:01:41 tkajinam I'm a bit confused because the spec mentions OVS-DPDK which likely require numa-aware allocation of cpu/mem
17:01:52 tkajinam while it might not be needed for virtio-fs thing
17:02:03 sean-k-mooney correct
17:02:18 sean-k-mooney memfd and numa affinity are ortoganal
17:02:26 sean-k-mooney if you want both you shoudl request both
17:02:59 tkajinam ok. that makes sense
17:03:52 sean-k-mooney today to use numa in nova you have to set hw:mem_page_size to any vallid value or use file backed memory
17:04:08 sean-k-mooney so memfd would not change that
17:05:18 tkajinam ok
17:14:36 Uggla dansmith, gouthamr, bauzas What I meant is during the PTG topic:
17:14:36 Uggla 1- We blocked actions on instances with an attached share to reduce the scope.
17:14:36 Uggla 2- Also mainly because older virtiofsd (<1.11) doesn’t support migration — per libvirt docs: “Older versions of virtiofsd (prior to 1.11) do not support migration…”, so ops like live-migration, save/restore, or memory snapshots may not work with a virtiofs share attached. (https://libvirt.org/kbase/virtiofs.html)
17:26:26 Uggla 3- So the blocked operation due to libvirt/qemu is not only live-migation but also suspend and shelve (I was unsure about the impacted ones during the call)
17:29:31 dansmith suspend I understand, but not shelve.. how does that have any requirement on libvirt/qemu?
17:33:48 sean-k-mooney i think we dont supprot snapshot and that the issue with shelve but we do allow nova to stop the vm to do snapshot
17:34:14 sean-k-mooney and for shelve specificly
17:34:23 sean-k-mooney we only do the snapshot in the shelve offload pahse
17:34:40 sean-k-mooney so the vm is stopped so ya i dont knwo why we could not od that today
17:35:20 dansmith I thought shelve did the snapshot not offload, but either way, the instance should be stopped already so yeah I can't think of why that would be a problem
17:43:31 sean-k-mooney offload might just bee the delete but i think the code path also diverges based on BFV vs image_type=rbd vs images_type=qcow
23:35:47 opendevreview chanyeol yoon proposed openstack/nova master: Fix infinite WARNING loop in _reclaim_queued_deletes https://review.opendev.org/c/openstack/nova/+/985068
#openstack-nova - 2026-04-21
01:52:07 opendevreview Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304
01:53:32 opendevreview Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304
05:52:37 opendevreview Ashish Gupta proposed openstack/nova master: Run functional test with threading mode https://review.opendev.org/c/openstack/nova/+/979850
05:52:38 opendevreview Ashish Gupta proposed openstack/nova master: Disable greenlet-based notifier sender check under native threading temporarily https://review.opendev.org/c/openstack/nova/+/985621
09:03:03 stephenfin gibi: sean-k-mooney: Morning 👋 Before the PTG kicks off, could I get some eyes on https://review.opendev.org/c/openstack/nova/+/985506? It's trivial but needed to unblock an u-c bump for o.vo
09:22:53 gibi stephenfin: done
09:23:08 stephenfin gibi++ ty 🙏
11:15:13 DominikDanelski[m] I missed signing-up for the virtual PTG for 2026.2. Doest that mean that adding https://review.opendev.org/q/topic:%22bp/numa-topology-with-rps%22 (NUMA Topology with Resource Providers) is dead in the water? Are specs / code changes reviewed, if they haven't been added to the agenda?
11:20:26 sean-k-mooney DominikDanelski[m]: no, the ptg is for gaining concencous not for approving any specific feaute
11:20:47 sean-k-mooney so 1 it cna still happen via the normal spec review process and 2 if there is time it can still be included in the ptg adgenda
11:22:44 sean-k-mooney the main issue i have with the current code is the reqrite of numa_fit_instance_to_host
11:23:18 sean-k-mooney it not clear to me that you fully undersstood what that fucniton was ment to do in the context of numa in placment
11:25:11 sean-k-mooney in the numa filtier its role is to determin if a given allcoation candiate can fullifle the the numa request so we can filter the canidate in the host state object
11:26:04 sean-k-mooney in the compute manger/resocue tracker claim its role i sgieve a singel allcoation candate generate the full instnac enuma toplogy and confirm its still valid
11:27:03 sean-k-mooney that code was intentially written in a functional style so that it was a pure input of the parmater with no sideffect which is why the object oriatneted rewrite makes it harder to revew as it break the mental model we had for that code
11:27:48 sean-k-mooney even if the code is effectivly equvlent https://review.opendev.org/c/openstack/nova/+/971176/9/nova/virt/hardware.py is an invaisve rewrite
11:35:28 opendevreview Anton Iacobaeus proposed openstack/nova-specs master: Intel TDX support in libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/979608
11:38:30 DominikDanelski[m] sean-k-mooney: Did you see my reply in https://review.opendev.org/c/openstack/nova/+/971176/1/nova/virt/hardware.py#b2509? I think the change to the overall logic is not as significant as it may look from the lines of diff, but I asked about your input there and I'm open to changes if you provide direction for them.
11:47:04 sean-k-mooney i did but again because it fundemtnally change the organstaion of the code i have not had tiem to fully unlopad all my expecations fo how that code shoudl work adn rereview it based on yoru changes
11:47:19 sean-k-mooney as i said that refactoring makes it a lot harder to review your change
11:50:42 sean-k-mooney if you wanted to make that easier to review you would do the refactor in its own patch that does not change any exisitng behivor. although im not entirly conveice that is the correct move. it would make it much clear what is jsut a refactorign vs behvior change
12:13:50 opendevreview Esra Ozkan proposed openstack/nova master: Check volume status before live migration https://review.opendev.org/c/openstack/nova/+/973750
12:22:15 opendevreview Elod Illes proposed openstack/nova stable/2025.2: fix: device_by_alias should respect config type https://review.opendev.org/c/openstack/nova/+/984920
12:24:08 sean-k-mooney Uggla: so its a little disapointing that the lack fo openstack client and sdk? supprot for nova share attatchment was not coverd in teh manilla cross project session
12:24:25 sean-k-mooney Uggla: i dont think we shoudl apcpate any new feature there really until that gap is closed
12:24:59 sean-k-mooney i dont object to any of the feature but without afctully coing that gap so you dont have to use curl im not sure we should keep exteneding it
12:25:18 sean-k-mooney oh...
12:25:22 sean-k-mooney sorry i msiste it
12:25:32 Uggla sean-k-mooney, good news the sdk and client were merged, it was the first topic of yesterday meeting.
12:25:47 sean-k-mooney ya i ddint see that initally
12:25:50 sean-k-mooney all good then
12:26:21 Uggla sean-k-mooney, gouthamr take over this and manage to cross the finish line.
12:27:15 Uggla sean-k-mooney no worries.
12:29:21 Uggla sean-k-mooney, also carloss presented good progress on the testing side.
12:30:42 sean-k-mooney shoudl i ask if said testing found bugs or not
12:33:16 Uggla sean-k-mooney, I would say yes at least one I'm aware of it --> 984802: Set instance to ERROR state on start_instance power_on failure | https://review.opendev.org/c/openstack/nova/+/984802
12:40:08 carloss sean-k-mooney: yep, the change Uggla linked was an issue gouthamr ran into. but so far, in the scenario (end to end) tests I have implemented, no further bugs found
12:40:37 carloss this is a job run using manila's cephfs native: https://zuul.opendev.org/t/openstack/build/f761d9016979435abe69c849a645ebc2
12:41:27 carloss I'm still figuring out why LVM (with NFS) is failing on CI because it's passing in a local env I have - so I think there's some mismatch in the env I own compared to the CI
12:41:57 carloss the share attachment tests are under the TestShareAttachmentCEPHFS class
12:44:36 sean-k-mooney Uggla: oh the resoume on host boot feature
12:45:00 sean-k-mooney ya im betting we didnt re attach the share or something?
12:45:04 sean-k-mooney that woudl have been easy to miss
12:48:22 opendevreview Merged openstack/nova master: objects: Prepare for oslo.versionedobjects 3.10.0 https://review.opendev.org/c/openstack/nova/+/985506
12:54:31 DominikDanelski[m] sean-k-mooney: OK, so I propose that we split the change in 2: first the behaviour change without the signature change (extending the function's behaviour at the expense of making it long), then the split which would end in the current state. It would be hard to show the refactor without the reason it's being done (extending behaviour).
13:56:10 opendevreview Karol Klimaszewski proposed openstack/nova-specs master: Spec for SPDK-based nova-provisioned storage backend https://review.opendev.org/c/openstack/nova-specs/+/985676
13:59:39 tkajinam as it's not likely we have time to discuss this... I wonder if that namespace package thing is what we broken when we removed pkg_resources ?
14:00:00 tkajinam I intended to keep that functionality but that was later broken by canonical folks insisting "this doesn't work for us"
14:00:43 tkajinam I might be confused by https://review.opendev.org/c/openstack/nova/+/939827 , though
14:01:20 tkajinam ok it seems nova.scheduler.filters has never been exposed as a namespace package
14:01:54 tkajinam we probably want to use the entrypoints approach instead
14:20:51 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: test if CLI testing hitting scatter gather https://review.opendev.org/c/openstack/nova/+/985681
14:30:56 opendevreview Karol Klimaszewski proposed openstack/nova-specs master: Spec for SPDK-based nova-provisioned storage backend https://review.opendev.org/c/openstack/nova-specs/+/985676
15:04:21 cardoe Thanks all for having the Ironic folks.
15:15:09 opendevreview Goutham Pacha Ravi proposed openstack/nova-specs master: Add spec for virtiofs hot attach and detach https://review.opendev.org/c/openstack/nova-specs/+/983816
16:43:36 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: test if CLI testing hitting scatter gather https://review.opendev.org/c/openstack/nova/+/985681
18:07:56 cardoe dansmith: I think my comments were misconstrued a little bit and I'd like to clear things up.
18:09:17 cardoe There's a number of users / operators of the nova-ironic driver that I'm aware of. That driver hasn't been a prime focus of the nova cores team so a lot of times patches kinda stall out a little bit. The testing for that driver in Zuul isn't the best as was highlighted during the call.
18:10:16 cardoe So what I'm doing is trying to get those users / operators to share some changes together that are important to them and trying to figure out the best way for us to voice that "this bug/issues is important to that group"
18:11:29 cardoe The reason for the repo idea is that more than once it's happened that I've spoken to one of them and they've said "oh we've iterated on the patch a little bit and use a new version". So just trying to come up with a way for them to do that more in the open.
18:17:52 dansmith cardoe: sounds pretty much like what you said on the call (although the context around it at the time is the important but). Sounds like a fork to me, which doesn't seem very constructive...
18:18:24 dansmith but, you don't need to convince me, I responded to your comment in the moment in the context of the moment
18:21:42 cardoe Can you give me suggestions how we get fixes that are important to the users of nova-ironic landed?
18:23:07 opendevreview Bryan Fraschetti proposed openstack/nova master: Reject to attach and detach volume while task_state is not None https://review.opendev.org/c/openstack/nova/+/758918
18:23:08 opendevreview Bryan Fraschetti proposed openstack/nova master: Feat: Add Command for Forceful BDM Deletion https://review.opendev.org/c/openstack/nova/+/985717
18:23:08 opendevreview Bryan Fraschetti proposed openstack/nova master: add task state for attach volume and detach volume https://review.opendev.org/c/openstack/nova/+/985718
18:23:09 opendevreview Bryan Fraschetti proposed openstack/nova master: Reject Volume Attachment if task_state not Attaching https://review.opendev.org/c/openstack/nova/+/985719
18:25:38 sean-k-mooney ok im goign to call it a day. ill be in the watcher session most fo tomorrow but if im meeded for a session ping me and ill try an attend
18:33:16 cardoe https://bugs.launchpad.net/nova/+bug/1884217 https://bugs.launchpad.net/nova/+bug/1732506 (mentioned by johngarbutt during the session) https://bugs.launchpad.net/nova/+bug/2127087 https://bugs.launchpad.net/nova/+bug/2085432 https://bugs.launchpad.net/nova/+bug/2131095 https://bugs.launchpad.net/nova/+bug/2148059 https://bugs.launchpad.net/nova/+bug/2117700
18:33:47 cardoe That's just the list of bugs that I'm aware of that operators have mentioned
18:35:52 cardoe I don't have a list of gerrit patches handy

Earlier   Later