| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-17 | |||
| 19:25:07 | Uggla | gibi, thanks, but regarding the hour 20:15 looks a bit late and not cool. I wish you a good WE and please rest during the WE. Next week will be intense. | |
| 20:43:58 | gibi | Uggla: thanks. It is complicated. :D | |
| #openstack-nova - 2026-04-19 | |||
| 03:24:52 | opendevreview | Goutham Pacha Ravi proposed openstack/nova-specs master: Add spec for virtiofs live and cold migration https://review.opendev.org/c/openstack/nova-specs/+/983801 | |
| 03:26:27 | opendevreview | Goutham Pacha Ravi proposed openstack/nova-specs master: Add spec for virtiofs live and cold migration https://review.opendev.org/c/openstack/nova-specs/+/983801 | |
| 04:30:44 | 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 | |
| #openstack-nova - 2026-04-20 | |||
| 02:19:04 | opendevreview | Merged openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | |
| 02:19:25 | opendevreview | Merged openstack/nova master: mem-enc: address minor issues pointed out in the review https://review.opendev.org/c/openstack/nova/+/983278 | |
| 05:46:50 | opendevreview | Goutham Pacha Ravi proposed openstack/nova-specs master: Add spec for virtiofs live and cold migration https://review.opendev.org/c/openstack/nova-specs/+/983801 | |
| 06:16:21 | opendevreview | Goutham Pacha Ravi proposed openstack/nova-specs master: Add spec for virtiofs live and cold migration https://review.opendev.org/c/openstack/nova-specs/+/983801 | |
| 06:40:07 | tafkamax | Hi, I have a question regarding nova-pythonclient. Will commands like nova reset-state <SERVER_ID> be migrated? | |
| 06:40:23 | tafkamax | So when python-openstackclient will become the only one standing. | |
| 06:42:37 | jkulik | Isn't it already available through `opennstack server set --state active`? | |
| 06:47:01 | tafkamax | oh okay, will try | |
| 08:47:48 | opendevreview | Kamil Sambor proposed openstack/nova master: Test nova CLI commands with native threading https://review.opendev.org/c/openstack/nova/+/984036 | |
| 12:27:28 | opendevreview | Kamil Sambor proposed openstack/nova master: Enable threading mode for proxy services https://review.opendev.org/c/openstack/nova/+/976089 | |
| 13:17:48 | bauzas | as a reminder, the PTG started for now, you can join us by clicking on https://meetpad.opendev.org/nova-2026.2-ptg | |
| 14:04:08 | dansmith | Uggla: didn't you just say we were supposed to be in the cinder room? | |
| 14:04:19 | dansmith | there was some confusion about where to be (here in the cinder room) | |
| 14:05:03 | Uggla | no liberty Nova room (sorry if it was not clear) | |
| 15:15:04 | melwitt | gibi: thanks for checking on the nova-vtpm patch. I saw it failed again :( so I will investigate | |
| 15:36:01 | gibi | Uggla: your nova bug stats will not like my effort of filing bugs for eventlet tech debt https://bugs.launchpad.net/nova/+bugs?field.tag=eventlet-removal | |
| 15:37:10 | gibi | melwitt: ack, thanks for trying to stabilize it | |
| 15:42:00 | stephenfin | tafkamax: https://docs.openstack.org/python-openstackclient/latest/cli/decoder.html | |
| 15:56:18 | opendevreview | Merged openstack/os-vif master: Bump min version of pyroute2 https://review.opendev.org/c/openstack/os-vif/+/984934 | |
| 16:10:10 | opendevreview | Stephen Finucane proposed openstack/nova master: objects: Prepare for oslo.versionedobjects 3.10.0 https://review.opendev.org/c/openstack/nova/+/985506 | |
| 16:10:30 | tkajinam | I'm just wondering how memfd works for allocation. Should we still calculate memory allocation according to the numa topology ? | |
| 16:10:48 | tkajinam | (assuming we still have to align cpu amd mem in numa-aware way, looking at it may be used for ovs-dpdk | |
| 16:11:26 | tkajinam | by the way memfd is heavily used in cc case (actually instances with snp support or tdx support uses it implicitly and it's interesting after learning the mechanism quite recently | |
| 16:22:28 | Uggla | @gibi, I think the bug you opened are valid so can be triaged. Anyway that's not too bad. | |
| 16:23:21 | Uggla | tkajinam, good to know memfd is something interesting for CC case. | |
| 16:23:40 | Uggla | tkajinam, if you have a doc pointer on it I'm interesting. | |
| 16:24:10 | Uggla | tkajinam, probably a good point to convince my mgmt that this feature is interesting. | |
| 16:46:03 | tkajinam | Uggla, let me find one, but it might not match your use case largely because 1) memfd is implicitly used by qemu 2) the main objective of using memfd is not performance but allocating private/encrypted memory for vm | |
| 16:50:00 | Uggla | tkajinam maybe part of an answer to your question --> https://lwn.net/Articles/990663/ | |
| 16:51:05 | tkajinam | ok so you still need to maintain memory:numa mapping (seeing that host-nodes=0) | |
| 16:52:18 | tkajinam | Uggla, this might be too-much information but captures the qemu's internal logic to leverage memfd for private memory area https://review.opendev.org/c/openstack/nova-specs/+/983376/comment/658b8a62_20071ca8/ | |
| 16:54:29 | sean-k-mooney | tkajinam: memfd can have the shared flag set or not i bleive | |
| 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. | |