On 15/04/2025 13:55, Rene Ribaud wrote:
Hello everyone,
Last week was the PTG—thank you to those who joined! I hope you enjoyed it.
I haven’t gathered exact attendance stats, but it seemed that most sessions had at least around 15 participants, with some peaks during the cross-team discussions.
If you’d like to take a closer look, here’s the link to the PTG etherpad: https://etherpad.opendev.org/p/r.bf5f1185e201e31ed8c3adeb45e3cf6d
We had a pretty full agenda for Nova, so here’s a summary I’ve tried to keep as short as possible.
This is a great summery of the sessions. its also quite long so im going to remove most of it in my rely. i have also provided my own personal summery of the nova session as part of my overall ptg summery blog https://www.seanmooney.info/blog/2025.2-ptg/#nova which should have similar info.
#### Cloud Hypervisor Integration ####
There is an ongoing effort to integrate Cloud Hypervisor into Nova via the Libvirt driver: Spec: https://review.opendev.org/c/openstack/nova-specs/+/945549
The current PoC requires only minor changes to work with Libvirt, and the team is ready to present the proposal at the PTG.
✅ We’re happy with the direction the spec is taking. Below are some key highlights regarding the spec. ✅ Clarify platform support (e.g., is libvirt compiled with cloud hypervisor support by default? Is it available in distros?). ✅ Provide a plan for runtime attach of multiple NICs and volumes. ✅ Mark as experimental if cloud hypervisor is not yet in upstream distro packages. ✅ Ensure that the following features are expected to work and covered in the spec: resize, migrate, rebuild, evacuate, snapshot. ✅ Justify raw-only image support, and outline the path to qcow2 compatibility.
i actully havent included this in my summary but i agree with the point you note above.
#### vGPU (mdev) and PCI SR-IOV Topics ####
1. Live-migratable flag handling (physical_network tag) Bug: https://bugs.launchpad.net/nova/+bug/2102161 <https://bugs.launchpad.net/nova/+bug/2102161> ✅ We agreed that the current behavior is correct and consistent with the intention: If live_migratable = false → fallback to hotplug during live migration. If live_migratable = true on both source and destination → prefer transparent live migration.
i also didnt call this out but yes that is what we agreed shoudl be the final behvior.
✅ Investigate how Neutron might participate by requesting live-migratable ports.
and we deferred this to a future release. we could do it via a number of means such as a trait request or a new extension or a generic hint/property on the port but we need guidance from the neutron team on there preference.
#### Moving TAP Device Creation from Libvirt to os-vif ####
This change proposes moving the creation of TAP devices from the Libvirt driver into os-vif, making it more consistent and decoupled. However, it introduces upgrade and timing considerations, especially regarding Neutron and OVN behavior.
Bug: https://bugs.launchpad.net/nova/+bug/2073254 Patch: https://review.opendev.org/c/openstack/nova/+/942786
✅ Neutron team is open to adjusting the timing of the "port ready" event, which could eliminate the need for Nova-side hacks. ✅ Sean will proceed with the patch and verify behavior through CI.
i have now done this and it passed https://review.opendev.org/c/openstack/nova/+/946950 so reviews are welcome. im undecided on if/how we should proceed with moving tap creation to os-vif. while i think that could be possible to do im not entirely sure how
#### Blocking API Threads During Volume Attachments ####
📌 Context: https://bugs.launchpad.net/nova/+bug/1930406 Volume attachment RPC calls block API workers in uWSGI, leading to starvation when multiple attachments are made in parallel.
✅ Volume/interface attachments should become async, reducing API lock contention. Fix is non-trivial and will require a microversion. In the meantime, operators may tune uWSGI workers/threads or serialize attachment calls.
ya. im slightly sad that we dont have anyone with time to work on this currently but its somethign we shoudl fix evenutally. unfotunetly as noted above it will need a semantic change in the api form blocking (200) to async (202) and that will need a micorversion so we will note be abel to fix this as a backportable bug fix.
If you've read this far — thank you! 🙏 If you spot any mistakes or missing points, please don't hesitate to let me know.
I think you did a good job capturing the actions items and main topics.
Best regards. René.