November 2025 - openstack-discuss

[kolla-ansible] Migration from OVS to OVN
by Winicius Allan 16 Feb '26

16 Feb '26

Hi kolla o/ I was searching to see if Kolla currently supports migration from OVS to OVN, and I've found this email thread [1]. I'd like to know if this feature has been implemented, and if so, what the necessary steps are. [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032785.h… Best regards

3 3

[kolla-ansible][rabbitmq] RabbitMQ cluster creation took too long
by Nguyễn Hữu Khôi 10 Feb '26

10 Feb '26

Hello. I am deploying OpenStack 2025.1 with Kolla-Ansible 2025.1 (master branch) using the latest images. However, when I created a RabbitMQ(4.0.x) cluster with 3 nodes, it took too long—around 12 minutes(it stucked at DB: virgin node -> run peer discovery). I then changed the images to RabbitMQ version 3.13.7, and it worked well. My OS: Ubuntu 24.01 Nguyen Huu Khoi

2 2

[openstack][octavia]Resize a Load Balancer
by Nguyễn Hữu Khôi 27 Jan '26

27 Jan '26

Hello. I see that patch https://review.opendev.org/c/openstack/octavia/+/890215 Could I ask why we cannot merge it? Nguyen Huu Khoi

3 6

[nova] Ephemeral storage potential features
by Karol Klimaszewski 26 Jan '26

26 Jan '26

Hello, In my company (CloudFerro) we have developed two features related to nova ephemeral storage (with libvirt virt driver) - "SPDK-based ephemeral storage backend" and "Multiple ephemeral storage backend handling" (both described below). Would these features be appropriate to be added to upstream? If yes, then should I start with creating a blueprint and proposing a spec for each of them so it is more clear what we want to introduce? Of course not both at once, since there is some code that makes one work with the other. For us it would probably be best if we upstreamed "SPDK-based ephemeral storage backend" first and then upstreamed "Multiple ephemeral storage backend handling" Description of SPDK-based ephemeral storage backend: We add a new possible value for [libvirt]/images_type in nova.conf: spdk_lvol. If this value is set then local disks of instances are handled as logical volumes (lvols). of locally run SPDK instance (on the same compute as VM). See https://spdk.io/doc/logical_volumes.html#lvol for docs on this subject. These are essentially a part of local NVMe disk managed by SPDK. We create and manage those lvols by making calls from nova-compute to SPDK instance with RPC (https://spdk.io/doc/jsonrpc.html) using provided python library (https://github.com/spdk/spdk/blob/master/python/README.md) We attach those lvols to instances by exposing them as vhost-blk devices (see https://spdk.io/doc/vhost.html) and specifying them as disks with source_type='vhostuser'. This method of exposing NVMe local storage allows for much better I/O performance than exposing them from local filesystem. We currently have working: creating, deleting, cold-migrating, shelving, snapshots, unshelving VMs with this storage backend. We don't have live migration working yet but have it in plans. This feature includes changes only to nova. Description of Multiple ephemeral storage backend handling: We add a new configuration option [libvirt]/supported_image_types to nova.conf of nova-compute and change the meaning of [libvirt]/images_type to mean default image type. If libvirt:image_type extra_spec is specified in flavor then VM is scheduled on compute with appropriate image type in its [libvirt]/supported_image_types. We use potentially multiple DISK_GB resource providers and construct appropriate request groups to handle this scheduling. This spec is also used to fill driver_info.libvirt.image_type field of BDMs with destination_type=local of this VM. (driver_info is new JSON serialized field of BDM) Then in compute if BDM specifies this field we use its value instead of [libvirt]/images_type to decide on imagebackend to use for it. This method of handling multiple backends only works after being enabled by administrators by setting libvirt:image_type on all their flavors and running nova-manage commands that update existing VMs. Without enabling everything works as it was before. This feature includes changes to nova and some new traits in os-traits (One per possible value of [libvirt]/images_type + one extra) Best regards, Karol Klimaszewski

2 7

[blazar] Extending the payload of a notification, to send the entire lease data
by NITIN GUPTA 16 Dec '25

16 Dec '25

Hello Blazar Team, May I have the following change reviewed, for extending the payload of a notification, to send the entire lease data: *https://review.opendev.org/c/openstack/blazar/+/965448 <https://review.opendev.org/c/openstack/blazar/+/965448>* Looking for your feedback as soon as possible. Best regards. -- NITIN GUPTA

2 9

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 08 Dec '25

08 Dec '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 14

[keystone][swift][ops] Is anyone using ec2token/s3token middleware in keystonemiddleware ?
by Takashi Kajinami 04 Dec '25

04 Dec '25

Hi, I was going through the codes in keystonemiddleware recently and I'm wondering if anyone is using the following middlewares maintained there ? - EC2Token - S3Token (Note that this is different from S3Token maintained within swift) I'm asking this question because these likely need to be updated to use authenticated access to keystone APIs due to recent vulnerability fix (s3tokens API and ec2tokens API now requires authentications by default). Technically we can fix these, but we would consider just deprecating these middlewares this cycle and removing them in H, if no one is actually using these. At least these codes have received no meaningful update for some years, and there is an indication of no usage like [1]. [1] https://review.opendev.org/c/openstack/keystonemiddleware/+/926459 This means s3token middleware was broken after identity v2 API removal, until this fix was merged in 2024 . Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 2

Making updates to SIGs (was: Re: [tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-19))
by Goutham Pacha Ravi 03 Dec '25

03 Dec '25

On Tue, Nov 18, 2025 at 1:48 AM Kees Meijs | Nefos <keesm(a)nefos.com> wrote: > > Hi, > > Could we please mark the Public Cloud SIG as "active" instead of "advisory" and replace Tobias and Huang by me Kees Meijs (keesm(a)nefos.com) please? > > Or, how can I do that myself? Hi there Kees! Thank you for checking; I wanted to bounce my response to the list because others may be in a similar situation of wanting to make Chair or documentation updates to the SIGs docs in the TC repo. Any contributor can propose changes to the SIG docs that are maintained here: https://opendev.org/openstack/governance/src/branch/master/reference/sigs In your case, you'd fix up the "chairs" and "status" for the Public Cloud SIG in https://opendev.org/openstack/governance/src/branch/master/reference/sigs/s… and submit your change through the OpenDev Gerrit. There is a bunch of one-time setup that's documented here: https://docs.openstack.org/contributors/code-and-documentation/quick-start.…. Please feel free to reach out if you have any questions. > > Cheers, > Kees > > On 17/11/2025 23:18, Goutham Pacha Ravi wrote: > > [3] OpenStack Special Interest Groups: > https://governance.openstack.org/tc/reference/sigs/ > >

2 1

[eventlet-removal][Neutron] neutron-dynamic-routing project status
by Rodolfo Alonso Hernandez 02 Dec '25

02 Dec '25

Hello all: Since [1], Neutron removed any dependency of "eventlet", including several auxiliary methods used by other projects, in particular neutron-dynamic-routing. We have been trying to clean-up this project, updating the requirements (removing eventlet, updating os-ken) and refactoring the DR agent classes (similar to what was done in the DHCP or L3 agents). But the DR agent is still failing [2], maybe due to an incorrect implementation in os-ken. However, due to the limited time we have, we cannot investigate it. *This email is a request for assistance in getting the users/developers of that project to remediate the code and remove the eventlet dependency.* This topic and the resolution taken was mentioned in the last Neutron meeting [3]. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/961210 [2]https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/956747 [3] https://meetings.opendev.org/meetings/networking/2025/networking.2025-11-18…

2 1

[Octavia][Load Balancer][2023.1] Amphora Fails Health Check – “No Route to Host” & Timeout Errors
by Thamanna Farhath 02 Dec '25

02 Dec '25

Hi OpenStack Community, I am currently facing an issue with the Load Balancer (Octavia) service in my OpenStack deployment and would appreciate your guidance or suggestions on how to troubleshoot and resolve it. Environment Details: OpenStack Version: 2023.1 (Antelope) Operating System: Ubuntu 22.04 Octavia Backend: Amphora Network Type: VXLAN Deployment Tool: Kolla Ansible Issue Summary: After creating a Load Balancer, the Amphora instance is successfully launched. However, approximately 18 minutes later, the Load Balancer transitions to an ERROR state. Error Observed: octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id a222527f-8336-4fb1-8e9e-0e3ac6e8d580 to go active timeout. octavia.amphorae.driver_exceptions.exceptions.AmpConnectionRetry: Could not connect to amphora, exception caught: HTTPSConnectionPool(host='192.168.200.247', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError: Failed to establish a new connection: [Errno 113] No route to host) What I’ve Tried: Created a VXLAN-based internal network: openstack subnet create --network octavia-mgmt-net --subnet-range 192.168.200.0/24 octavia-mgmt-subnet openstack router create octavia-router openstack router add subnet octavia-router octavia-mgmt-subnet openstack router set octavia-router --external-gateway <public-network-id> Manually configured OVS interface: ovs-vsctl add-port br-int octavia-mgmt -- set interface octavia-mgmt type=internal ip addr add 192.168.200.1/24 dev octavia-mgmt ip link set octavia-mgmt up Security groups are open (allowing all ingress and egress). Verified OVS bridge setup – interface appears correctly on br-int. Behavior Noticed: Amphora instance gets created but fails to communicate with the controller after a while,so health checks fails. The controller cannot reach the Amphora management IP (192.168.200.x). Logs show heartbeat/connection issues (No route to host, timeouts). Request for Help: I would appreciate any of the following: Suggestions to verify if the management network is properly routed from controller to Amphora. Best practices for setting up the Octavia management network using VXLAN. Troubleshooting steps for verifying health manager connectivity to Amphora. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 3

[nova] migration status update too long
by Nguyễn Hữu Khôi 28 Nov '25

28 Nov '25

Hello. I am working on instance migration. After I complete the migration, when I run *openstack server migration list* to check its status, it still shows as *running*. It takes around *12 minutes* before it updates to *completed * status. My OPS: 2025.1 Thank you. Nguyen Huu Khoi

3 12

[openstack-ansible][rabbitmq] Repository change from ppa1 to deb1 for Ubuntu/Debian
by Dmitriy Rabotyagov 28 Nov '25

28 Nov '25

Hi folks, Recently RabbitMQ has changed a repository URL for RabbitMQ and Erlang packages for Ubuntu and Debian. We were using ppa1.rabbitmq.com for all our stable branches, which used to work nicely until recently. With that being said, all existing users need to update their configuration, to use a new repository. For that: * Download GPG key to your deploy host (the one referenced on https://www.rabbitmq.com/docs/install-debian) curl -1sLf https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73… -o /etc/openstack_deploy/pki/rabbitmq.gpg * Create /etc/openstack_deploy/group_vars/rabbitmq_all.yml with content: rabbitmq_repo_url: https://deb1.rabbitmq.com/rabbitmq-server/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_erlang_repo_url: https://deb1.rabbitmq.com/rabbitmq-erlang/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_gpg_keys: - file: /etc/openstack_deploy/pki/rabbitmq.gpg This should fix all existing deployments, while we are proposing and backporting patches for all maintained branches. So a proper fix is expected with the next bugfix release.

2 2

[barbican] Review Request: Fix rewrap_pkek with SoftHSMv2 and CKM_AES_KEY_WRAP_PAD key wrap mechanism (I965443)
by Kaoru Watanabe 27 Nov '25

27 Nov '25

Hi OpenStack Barbican Community, This is my first time submitting a patch to OpenStack, and I am sending this email to kindly request a review. I have great respect for the work you all do in this community. I submitted a patch to address a critical issue we found. This issue occurs when performing key rewrap (barbican-manage hsm rewrap_pkek) using SoftHSMv2 and the CKM_AES_KEY_WRAP_PAD key wrap mechanism. This specific configuration is essential for our production environment, making this fix highly critical for us. We would be grateful if this patch could be merged. Here are the details: Bug Report: https://bugs.launchpad.net/barbican/+bug/2130214 Gerrit Change: https://review.opendev.org/c/openstack/barbican/+/965443 (I965443) The change has been posted for almost a month now. Could you please take a moment to review change I965443? Your feedback is greatly appreciated as we look to move this forward. Thank you very much for your time and collaboration. Best regards, kaoru

1 0

[barbican] Review Request: Fix rewrap_pkek with SoftHSMv2 and CKM_AES_KEY_WRAP_PAD key wrap mechanism (I965443)
by kaoru watanabe 27 Nov '25

27 Nov '25

Hi Openstack Barbican Community, This is my first time submitting a patch to OpenStack, and I am sending this email to kindly request a review. I have great respect for the work you all do in this community. I submitted a patch to address a critical issue we found when performing key rewrap (barbican-manage hsm rewrap_pkek) using SoftHSMv2 and the CKM_AES_KEY_WRAP_PAD key wrap mechanism. Bug Report: https://bugs.launchpad.net/barbican/+bug/2130214 Gerrit Change: https://review.opendev.org/c/openstack/barbican/+/965443 (I965443) This specific configuration (SoftHSMv2 with CKM_AES_KEY_WRAP_PAD) is essential for our production environment, making this fix highly critical for us. We would be grateful if this patch could be merged. The change has been posted for almost a month now. Could you please take a moment to review change I965443? Your feedback is greatly appreciated as we look to move this forward. Thank you very much for your time and collaboration. Best regards, kaoru

1 0

Arbitrary qemu args in nova-compute
by Nathan Harper 27 Nov '25

27 Nov '25

Prompted by Sean’s comment on a different thread: * nova has a policy of not allowign any use of raw qemu args I’ve seen this come up a number of times, but I don’t recall seeing the justification for this policy. We are looking at a scenario where we (as an operator) want to add some specific additional qemu flags to some VMs, but we’re now having to run a local Nova patch to achieve this (experiments with libvirt-hooks haven’t proven fruitful. I can see why we wouldn’t want users to add arbitrary flags, but an unsupported YMMV option in Nova would be helpful -- Regards, Nathan Harper Principal Engineer – Cloud Development Platform Engineering nathanh(a)graphcore.ai<mailto:nathanh@graphcore.ai> www.graphcore.ai →<http://www.graphcore.ai/> ** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<http://www.graphcore.ai/privacy> ** This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information. If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful. Any personal data/special category personal data herein are processed in accordance with UK data protection legislation. All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company. Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at, 1 Maple Road, Bramhall, Stockport, Cheshire, UK, SK7 2DH. This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.

2 2

[nova][keystone] Machine identities
by Ricardo Cano 27 Nov '25

27 Nov '25

Hey guys, I was wondering if openstack had an equivalent to Azure's managed identities or AWS's IAM roles for ec2 to give vm's the ability to interact with the api. Are there any existing patterns that people are using for this? Thanks!

5 4

Q35 UEFI machine cannot fully load pci device "cannot find enough free resources (Code 12)”
by Joel McLean 27 Nov '25

27 Nov '25

G'day OpenStackers. I've got a fun one for the nova gurus among us. It could be that there exists documentation that answers this specific problem, but I am yet to come across it. Recently we've been playing around with GPU PCI Passthrough, using a couple of SMX4 NVIDIA A100s. We don't intend on slicing these up with MIG as they're small cards, and so have just been trying to get passthrough working. Following the documentation [0] , we've got it working in Ubuntu VMs after some troubleshooting, which I will share below in case it helps anyone else; we ran into problems with the default QEMU q35 hole size, and worked around the problem by modifying the grub config. However, we're not yet able to make it work with Windows. For reference, this is on a Caracal 2024.1 deployment of OpenStack. Essentially for the ubuntu 24 VM the description of the problem was: # Problem - on Ubuntu ## Replication Steps: 1. Create new instance from image with properties "hw_machine_type=q35" and "hw_firmware_type=uefi", and OS as Ubuntu 24, using flavor with a100-40g attached 2. Log into instance and install nvidia-drivers-580 ## Bug conditions: lspci shows that gpu is present drivers are able to be installed nvidia-smi command fails with error message unable to connect to drivers dmesg | grep pci - shows error message for pci device: [ 1.180865] pci 0000:05:00.0: BAR 0 [mem 0xff000000-0xffffffff]: can't claim; no compatible bridge window [ 1.182544] pci 0000:05:00.0: BAR 1 [mem 0xfffffff000000000-0xffffffffffffffff 64bit pref]: can't claim; no compatible bridge window [ 1.184541] pci 0000:05:00.0: BAR 3 [mem 0xfffffffffe000000-0xffffffffffffffff 64bit pref]: can't claim; no compatible bridge window [ 1.416571] pci 0000:05:00.0: BAR 1 [mem size 0x1000000000 64bit pref]: can't assign; no space [ 1.418209] pci 0000:05:00.0: BAR 1 [mem 0xfffffff000000000-0xffffffffffffffff 64bit pref]: failed to assign [ 1.420057] pci 0000:05:00.0: BAR 3 [mem size 0x02000000 64bit pref]: can't assign; no space [ 1.423133] pci 0000:05:00.0: BAR 3 [mem 0xfffffffffe000000-0xffffffffffffffff 64bit pref]: failed to assign [ 1.424987] pci 0000:05:00.0: BAR 0 [mem 0x80000000-0x80ffffff]: assigned [ 1.545824] pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc lspci -v shows memory BAR0 as disabled, does not show BAR1 or BAR3 at all: root@test-gpu-2:~# lspci -v -s 05:00.0 05:00.0 3D controller: NVIDIA Corporation GA100 [A100 SXM4 40GB] (rev a1) Subsystem: NVIDIA Corporation GA100 [A100 SXM4 40GB] Physical Slot: 0-4 Flags: fast devsel, IRQ 255 Memory at 80000000 (32-bit, non-prefetchable) [disabled] [size=16M] ## Solution: Modify and append the grub configuration with: GRUB_CMDLINE_LINUX="pci=realloc pci=nocrs" Then save and update-grub, and reboot. The nvidia-smi command now works, all 3 memory BARs show up, everything works, no more error messages. This means we're able to have GPU-capable linux images by having this modification baked into the image, or if appropriate, the cloudinit. # Problem - but on Windows However, on Windows (tested on server 2022 and server 2025), we run into the same problem : Windows seemingly cannot allocate enough memory to properly load the device; it appears in device manager, appears to be recognised, but stalls indefinitely during driver installation. Microsoft's available logging isn't as nice or as usable as Ubuntu, but the vibe of the logs is the same: Windows throws an error “This device cannot find enough free resources (Code 12)”. ## Possible Solutions We found that we could pass qemu arguments to the VM that would resolve the issue, but this is not viable in OpenStack as we can't pass the qemu arguments from the flavor or image meta-data. This solution gets thrown around on PVE forums or lxc/libvirt only areas, as it's not really openstack/nova friendly. The arguments (where VMID is the ID of the instance) to make it work were: qm set {VMID} -args '-global q35-pcihost.pci-hole64-size=256G' (run on the nova_libvirt container that controls the instance) As a note, I just could not find any documentation specifically (e.g. on qemu.org's documentation portal) that talks about q35-pcihost features, or specifically how pci-hole64-size interacts with the system. As you can imagine, setting arguments directly in the libvirt container isn't viable, as making modifications to libvirt outside of nova is against the whole cloud-native idea of Nova. It's just not meant to work that way. Alternatively, we've been able to get it working on an i440fx BIOS, as opposed to a q35 in UEFI, but that doesn't really feel like the right way to approach this problem. Any ideas on a good, cloud-native way to either modify our nova.conf, create a flavor, or update an image/image metadata so that a modern q35/UEFI machine running Windows can load the device properly? Thanks in advance. [0] ( https://docs.openstack.org/nova/latest/admin/pci-passthrough.html ) Kind Regards, Joel McLean Cyber Security and Product Development Manager Australia’s First Tier IV Data Centre https://www.micron21.com/ 1300 769 972 03 9751 7618 0407 888 429 joel.mclean(a)micron21.com Follow us on Twitter and https://m21status.com for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

2 1

[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Artem Goncharov 26 Nov '25

26 Nov '25

Hey, I took a stab for the first actions, which I added to the wiki page [1] by dropping the dependencies which are clearly not used or not necessary today. For that I proposed removing passlib [2], scrypt [3], and python-gnupg [4] from requirements completely. I do not know whether we have a proper mechanism of forbidding certain libs from being used to protect us from somebody accidentally re-starting using them (denylist is in the requirements, but I am not sure it was created for such purpose). ## Passlib it is abandoned. It was used in Keystone, but we got rid of it a few releases ago. Now there are few projects that install passlib (Kolla, OpenStack-Ansible, etc) but not themselves needing it. Those show drop it as well, but maintainers should be aware by now already ## scrypt Keystone was the only project using it. In the context of passlib replacement corresponding functionality was used from the cryptography library. Standalone use of scrypt should not be necessary ## python-gnupg Codesearch does not show any project using that. Regards, Artem [1] https://wiki.openstack.org/wiki/Post_quantum_openstack#Action_points [2] https://review.opendev.org/c/openstack/requirements/+/968443 [3] https://review.opendev.org/c/openstack/requirements/+/968444 [4] https://review.opendev.org/c/openstack/requirements/+/968445

1 0

[neutron] Drivers meeting canceled Friday, November 28th
by Brian Haley 25 Nov '25

25 Nov '25

Hello Neutrinos: I am going to cancel Friday's Drivers meeting as I will be out the rest of the week. Just a reminder that our open spec list at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[ironic] Team meeting cancelled for December 22nd and 29th
by Julia Kreger 25 Nov '25

25 Nov '25

Greetings Ironic community members! During our weekly meeting on November 24th[0], I raised the question if we should skip our weekly meeting on December 22nd and 29th due to the end of year. We reached consensus to go ahead and cancel those meetings as we expect the bulk of contributors to be taking time off during those weeks. As a result, the last formal Ironic team meeting of 2025 will be on December 15th, and the weekly meeting shall resume on January 5th, 2026. Thanks, -Julia [0] https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-11-24-15.02.l…

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-18)
by Goutham Pacha Ravi 24 Nov '25

24 Nov '25

Hello Stackers, We're eighteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Next Thursday is the deadline for project deliverables following the "trailing" [2] release model to ship their final releases for the OpenStack 2025.2 "Flamingo" release. This includes packaging, deployment, configuration, and lifecycle tooling projects that have bundled the goodness of the past release in a consumable way. The rest of the OpenStack project teams are in the thick of the Gazpacho roadmaps they've drawn for themselves. Now is a good time to ensure that any project-specific deadlines are added to the community's release calendar [1], like the Nova and Manila project teams have done. In the past week, the OpenStack Technical Committee did not make any major governance updates. We continued work on bringing the Special Interest Groups under the "openstack/governance" repository so we can provide them with the increased focus, visibility, and oversight that they currently lack. We also made significant progress on the retirement of the Monasca project deliverables; we hope to conclude it soon. === Weekly Meeting === The TC met on OFTC's #openstack-tc channel on November 18, 2025 [3]. This was the second occurrence of our monthly meeting at an APAC-friendly time. We do hope to energize the community into focused discussions in this new, periodic slot. Bear with us while we get past our teething troubles here. The meeting focused on moving several stale volunteer-needed items, such as analyzing the user survey results and reworking FIPS requirements, to the TC tracker due to a lack of current interest or traction. We discussed the Zuul errors on the cleanup patches concerning the Monasca project. We noted that it was past time to get this done, especially since some potential users claimed that their use case was at least a year out. Retiring a project within OpenStack is not the end of the road for the project. Volunteers are welcome to fork the project and continue its development outside OpenStack's governance. We do hope that Monasca continues to be developed outside the aegis of OpenStack's governance, and can return someday when there is interest to drive it within this community. The TC also discussed the proposed oslo.wsgi library and deemed it a good idea and will welcome any governance patches. The health of the gate looks good, with recent Gerrit and Gitea updates proceeding smoothly. The discovery of a new Zuul feature allowing the scheduler to be paused during Gerrit unavailability was identified as a time-saver. The next meeting of the OpenStack Technical Committee is on Tuesday, November 25, 2025, at 1700 UTC. The meeting will be hosted on OFTC's #openstack-tc channel. Please find the agenda on the meeting's wiki page [4]. I hope you'll be able to join us. === Governance Proposals === ==== Open For Review ==== * Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 * [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 * Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 * 2025-11-17 Retirement and Handover of the os-net-config Project | https://review.opendev.org/c/openstack/governance/+/967463 === Upcoming Events === * 2025-12-04: 2025.2 release deadline for "cycle-trailing" projects * 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ * 2026-01-08: 2026.1 Milestone 2 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack release models: https://releases.openstack.org/reference/release_models.html [3] TC Meeting IRC Log, Nov 18, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-18-17.01.html [4] TC Meeting Agenda, Nov 25 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 1

[qa] devstack & hacking core member updates
by Ghanshyam Maan 24 Nov '25

24 Nov '25

Hello everyone, I would like to propose the following updates to the devstack and hacking project core member list: Devstack: - Adding gibi in devstack core. He has been fixing and helping in devstack for a long time. Hacking: - Adding stephenfin and sean-k-mooney in the hacking core members list. Both have a good understanding of hacking projects and helping there on a need basis. - Frickler and I are part of the hacking core, but via included groups. I will be moving both to the core member list explicitly. Feel free to provide your feedback. If there are no objections by this Friday (21st Nov), I will update the gerrit group. -gmaan

2 2

[tc][horizon]Request for guidance on improving Python PTI doc to include pytest for Horizon plugins testing
by Chandan Kumar 24 Nov '25

24 Nov '25

Hello TC, We are writing to seek your guidance regarding the Python testing standards (PTI) as they relate to Horizon plugins. The current integration tests of the watcher-dashboard project (the Horizon plugin for OpenStack Watcher) are broken due to integration code changes in the Horizon integration suite. We are currently working on rewriting the watcher-dashboard integration tests. We noted that the Horizon project itself has developed a robust set of reusable, pytest-based integration tests, fixtures, tox targets and zuul job[1]. We also see that other plugins, like manila-ui, are already reusing these pytest fixtures.[2]. Several other projects within the OpenStack ecosystem (such as skyline-apiserver, rally, and projects under the Airship and StarlingX namespaces) are already using pytest. This presents a conflict for the Watcher team. The official Python PTI states that tests should be written using the Python stdlib unittest module[3]. The Watcher team advocates for adhering to the Python PTI and using unittest. Our main watcher project uses unittest, and we prefer to maintain this standard for consistency and PTI compliance in watcher-dashboard. This topic came up during watcher PTG discussion[4]. This leaves us with a dilemma: - Follow the Python PTI: This aligns with the PTI and our team's standards but requires us to ignore Horizon's reusable pytest tests and build our own testing framework from scratch, duplicating effort. - Follow the parent project (Horizon) to use pytest to reuse their fixtures. This would be more efficient but appears to violate the Python PTI and creates inconsistency with our main project. - Do we want to improve Python PTI documentation to include pytest usage? We just need guidance on this topic. Links: [1]. https://github.com/openstack/horizon/tree/master/openstack_dashboard/test/s… [2]. https://github.com/openstack/manila-ui/tree/master/manila_ui/tests/selenium [3]. https://github.com/openstack/governance/blob/master/reference/pti/python.rs… [4]. https://etherpad.opendev.org/p/watcher-2026.1-ptg#L404 With Regards, Chandan Kumar

10 22

[kolla] Cancelling weekly meeting on 26th Nov 2025
by Michał Nasiadka 24 Nov '25

24 Nov '25

Hello Koalas, We need to cancel the weekly meeting this week due to unavailability of key participants (including me). See you on the meeting 3rd of Dec. Cheers, Michal

1 0

[Neutron][VPNaaS] Multiple tunnels per IPSec Service
by Shubham Yadav 24 Nov '25

24 Nov '25

Hello OpenStack Community, I'm working with OpenStack VPNaaS (using strongSwan as the backend driver) and have a question about tunnel configuration capabilities. *Current Setup:* OpenStack VPNaaS with strongSwan driver (StrongSwanDriver) Single VPN Service (gateway) with multiple IPSec Site Connections Each connection targets different remote peers with distinct subnets *Configuration Details:* VPN Service: Connected to a single router Multiple IPSec Site Connections under the same VPN Service: Connection 1: To MY office (10.10.100.0/24) via peer 68.x.y.34 Connection 2: To Rackspace (172.24.60.0/22) via peer 184.n.p.53 Shared IKE and IPSec policies across connections Local endpoint groups covering multiple subnets (192.168.0.0/24, 10.43.0.0/16) *Question:*Is it supported/recommended to have multiple IPSec Site Connections under a single VPN Service? I understand this creates multiple tunnels from the same OpenStack router to different remote peers. *Current Issue:*One of my connections shows "PENDING_CREATE" status while the other is "ACTIVE". I'm trying to determine if this is: A configuration issue on my end A limitation of having multiple tunnels per VPN service A strongSwan-specific behavior in the OpenStack context *Specific Questions:* Does VPNaaS officially support multiple IPSec connections per VPN Service? Are there any known limitations or best practices when using multiple tunnels? Should each remote site have its own dedicated VPN Service instead? I've checked the documentation but couldn't find clear guidance on multi-tunnel scenarios. Any insights from the community would be greatly appreciated. *Environment:* OpenStack version: 2024.2 Dalmatian Neutron VPNaaS with strongSwan backend Kubernetes-deployed OpenStack (OpenStack-Helm) Thank you for your time and assistance! Best regards, Shubham

2 1

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 23 Nov '25

23 Nov '25

Hi team, Due to a holiday in Japan and most of team members aren't join, I'm cancelling meeting this week. Regards, Yasufumi

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on November 21, 2025
by Ildiko Vancsa 22 Nov '25

22 Nov '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __November 21st, 2025 at 1300UTC,__ which is this Friday! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. We had a great discussion at the last meeting about how to refactor Ops-related activities - See Thierry's email for initial details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - Meeting notes from October 31st: https://etherpad.opendev.org/p/openstack_ops_radiohour This upcoming call is a great opportunity to discuss and take next steps towards a more cohesive way for Ops folks to gather, discuss challenges and possible solutions, and onboard new operators and users to the community! If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> <https://matrix.to/#/%23openstack-ops:opendev.org%3Chttps://matrix.to/%23/%2…> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on November 21st! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[nova][libvirt][qemu] Windows 11 Nested Virtualization Boot Loop on OpenStack (Emerald Rapids Hosts)
by Hai Pham Thanh 21 Nov '25

21 Nov '25

Hi community, We would like to report an issue we are encountering with nested virtualization on Windows 11 instances running on OpenStack. On our OpenStack platform, a Windows 11 VM becomes unable to boot after enabling Virtual Machine Platform/Hyper-V inside the VM and performing a hard reboot (VM does not show a BSOD but fails to boot into the OS and gets stuck in a boot loop in Tianocore logo). This issue does not occur on Windows 10 under the same conditions. System: * Compute node CPU: Intel Xeon Gold 6538Y+ (Emerald Rapids) with nested virtualization is enabled. * OpenStack 2024.2 * libvirt 8.0.0 * QEMU API 8.0.0 * QEMU hypervisor 6.2.0 Initially, our Nova CPU configuration was: * cpu_mode=host-model * cpu_model_extra_flags=+vmx,-hypervisor,-xsaves According to virsh dumpxml, host-model maps to Icelake-Server. We tested several cpu_mode=custom configurations and observed the following: * cpu_models=Icelake-Server-noTSX → error (boot loop) * cpu_models=Icelake-Server → error (boot loop) * cpu_models=Broadwell-noTSX-IBRS → works * cpu_models=Cascadelake-Server-noTSX → works The working models correspond to the Preferred CPU models recommended by QEMU: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#preferred-c… We would like to ask: 1. Has anyone encountered this issue with Windows 11 + nested virtualization on Icelake/Emerald Rapids hosts? 2. Are there known root causes explaining why newer CPU models fail while preferred (older) models work? 3. Is there a recommended fix other than switching to a preferred older CPU model? Best regards, Hai Pham

4 5

[kolla-ansible][firewalld] Initializing firewall rules for new services
by Jonathan Proulx 21 Nov '25

21 Nov '25

Hi All, Continuing to run through my expoy testing depoly I enabled firewalld management (I think) with: disable_firewall: "false" enable_external_api_firewalld: "true" After predeplying firewalld on the control nodes and adding the public IP interface and an ssh allow rule (and a few other internal allows for $REASONS). This seemed to work for the services I had deployed, but when installing a new service (magnum for example) the API port 9511 is listening on the controllers but blocked externally. There doesn't seem to be a firewall or firewalld tag, is there something else I need to poke? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

1 0

[Nova] Nova bug triage follow-up & volunteer roster proposal
by René Ribaud 21 Nov '25

21 Nov '25

Hi everyone, Following our recent discussions about improving our upstream bug triage process, here’s a *Goal:* Improve bug follow-up and make sure each reported issue gets attention, while keeping the workload balanced across contributors. *Proposed process:* 1. Create a list of volunteers interested in helping with bug triage. 2. Each week, Uggla will distribute a few bugs (no more than 3 per person) to the volunteers’ group for review and follow-up. 3. During the upstream meeting, we’ll briefly check if a *dedicated session* is needed to discuss any specific bugs. 4. If needed, we’ll schedule a *Q&A session every two weeks* (or less frequently if not required). 5. If not, we’ll simply handle questions or updates directly within the upstream meeting. The dedicated session could take place right after the upstream meeting. Please add your name to the Etherpad below if you’d like to volunteer: https://etherpad.opendev.org/p/nova-bug-triage-roster Thanks everyone for your help keeping our bug list healthy and up to date! Cheers, René

2 1

[manila] No IRC meeting next week (Thu, Nov 27th 2025)
by Goutham Pacha Ravi 20 Nov '25

20 Nov '25

Hello Zorillas and interested Stackers, The Manila team's weekly meeting next week (Nov 27th 2025) has been cancelled due to a lack of quorum. This could be a theme for a few weeks in the remainder of 2025 as we hit local holidays and end-of-the-year holidays observed around the world. Please follow the meeting's wiki page for updates [1]. In the meantime, feel free to chime in on OFTC's #openstack-manila. The next weekly IRC meeting will be on December 4th 2025 at 1500 UTC in #openstack-meeting-alt on OFTC. Thanks, Goutham Pacha Ravi [1] https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting

1 0

[hacking][all] Expanding set of import exceptions
by Stephen Finucane 20 Nov '25

20 Nov '25

o/ I've been slowly adding type hints to oslo and SDK projects of late as time has allowed. One thing that I've noticed is that strict adherence to hacking's H301 (Do not import more than one module per line) and H303 (Do not use wildcard * import) rules results in both stupidly long groups of imports and overly verbose and difficult to read signatures [1]. I've therefore proposed a change to these rules that exempt some typing-related libraries - collections.abc, types, and typing - from these rules. This is proposed at [2]. As noted there, exceptions already exist for the sqlalchemy and projects' i18n modules for the same reason so this should be nothing new. I am instead bringing this up so projects currently using e.g. 'import typing as ty' imports can pivot to something sooner once this is merged. Cheers, Stephen [1] If you've already started writing a reply about how type hints *themselves* make function signatures more verbose and difficult to read, (a) is your name Sean Mooney and (b) stop right there, go enable an LSP in your editor, then come back to me in a month once you've seen the quality of life improvement hints provide. Then we'll talk 😄 [2] https://review.opendev.org/c/openstack/hacking/+/967719

4 7

openstack server create fails with: Invalid PCI alias definition: Expecting property name enclosed in double quotes
by Sigurd Kristian Brinch 20 Nov '25

20 Nov '25

When I try to create a VM with: openstack server create and the flavor has a property set with "pci_passthrough:alias"="NVIDIA-H200-35C:1" The error message is: novaclient.exceptions.BadRequest: Invalid PCI alias definition: Expecting property name enclosed in double quotes: line 1 column 29 (char 28) (HTTP 400) (Request-ID: req-66fb38d8-8f49-4073-99a2-fa4677d9b48e) Anyone have any idea what is causing this? A similar command worked fine just last week. Attached is the debug output from the create command BR Sigurd

2 2

[horizon] Considering a change in how SCSS styles are handled
by Radomir Dopieralski 19 Nov '25

19 Nov '25

Hello everyone, while working on some other part of Horizon, I recently looked at the source of the pages generated, and noticed that a substantial amount of each page is the style, compiled and included on every single page using the <style> tags. That is a rather bad practice for a number of reasons, from performance to waste of bandwidth. I decided to see if that could be easily fixed, so prepared this patch that instead includes the compiled style using a <link> tag: https://review.opendev.org/c/openstack/horizon/+/966665 Now, I'm writing to this list for two reasons. The first is to make sure that there isn't some rule or regulation, possibly introduced before the Web was invented, that requires all OpenStack software to handle the styles in that way, and that we would be breaking if we went with my patch. The second is of a more technical nature, and pertains to the change that had to be made to the `_components.scss` file in that patch. In short, a similar change would have to be done in any Horizon plugin that adds style sheets to `HORIZON_CONFIG.scss_files`. Since we don't have control over Horizon plugins and can't possibly force such a change, and since merging my patch without such changes would break the plugins, I would like to hear from the plugin maintainers about the best way to proceed with this (or, just leaving things as they are, if that is the better option). The change becomes necessary, because the included `scss_files` can no longer be compiled in one huge block with the rest of horizon's styles, but have to be included with their own <link> tags as separate files, which means that any dependencies they rely on have to be explicitly included using the `@import` mechanism. Most of those styles at the minimum will rely on the common variables from the theme, that's why this particular import, but there may be a need for more imports added depending on what the stylesheet in question uses. I'm also open to suggestions on how to avoid the need for this change and compile everything in one big blob as we are doing now, but don't inline the style on every page. Between Django, Django-compressor, SCSS compiler and template mechanism, I don't currently see a way to do this. Thank you for your feedback, -- Radomir Dopieralski

2 1

[cinder] festival of reviews friday 2025-11-21
by Brian Rosmaita 19 Nov '25

19 Nov '25

Hello Argonauts, This is a reminder that the most recent edition of the Cinder Festival of Reviews (no longer extra-small!) will be held at the end of this week on Friday 21 November. who: Everyone! what: The Cinder Festival of Reviews when: Friday 21 November 2025 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics (though for some reason, the november 2025 meetings don't show up) See you there!

1 0

GPU card for multiple users
by KK CHN 19 Nov '25

19 Nov '25

List, I am having NVIDIA L40s, PCle GPU installed in one of Ubuntu Server Box, How can I make use this NVIDIA L40s card to support multiple users for running their AI work loads. How to achieve this virtualization support for the NVIDIA Card. Some body can shed some light on this regard , what are the steps need to perform to get the GPU card virtualized ? Thanks in advance, Krishane

2 2

[2023.1][kolla][rabbitmq] Failing to get packages from RabbitMQ Repos
by Rob Jefferson 18 Nov '25

18 Nov '25

Folks, At work, we're using Kolla 2023.1, and during a recent build, I saw that the PPA that provided RabbitMQ packages gave me a "402 Payment Required" error. This seems to be an existing problem, so I decided to try using the PPA that's in the current version of 2023.1 Kolla. When I change the repo in `kolla/templates/repos.yml` so that the URL is https://ppa1.rabbitmq.com/rabbitmq/rabbitmq-server/deb/ubuntu and the key in `docker/base/Dockerfile.j2` to be 9F4587F226208342, I get the following error: > E: The repository 'https://ppa1.rabbitmq.com/rabbitmq/rabbitmq-server/deb/ubuntu jammy Release' does not have a Release file. If, on the other hand, I use the PPA in the official RabbitMQ docs: https://deb1.rabbitmq.com/rabbitmq-erlang/ubuntu/jammy And use the key 0A9AF2115F4687BD29803A206B73A36E6026DFCA, I get the following error: > W: GPG error: https://deb1.rabbitmq.com/rabbitmq-server/ubuntu/jammy jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6B73A36E6026DFCA > INFO:kolla.common.utils.rabbitmq:E: The repository 'https://deb1.rabbitmq.com/rabbitmq-server/ubuntu/jammy jammy InRelease' is not signed. In both cases, I'm not sure what the issue is. I would have expected RabbitMQ server for Jammy to still be available in the first case (especially since that PPA remains in Kolla), or for the key I used in the second case to exist. Is there something I can try to fix this issue? Thanks, Rob

4 4

Updating Monitor List (rbd section) using Virsh with no downtime
by m.riudalbas＠first-colo.net 18 Nov '25

18 Nov '25

Hello, is there a way to update a monitor list of the rbd section in a virtual machine? We need to add or modify the following entries. <source protocol='rbd' name='cinder/volume-343766ad-0086-4f8c-a557-bc60ba2210f4' index='1'> <host name='172.16.65.164' port='6789'/> <host name='172.16.65.165' port='6789'/> <host name='172.16.65.166' port='6789'/> </source> We want to replace the Monitor network and this means that we have to update every virtual machine with the new Ceph monitor IPs. The only way to replace them is with a live migration (then the live ceph configuration with the new IPs will be applied), but we would like to know if there is a faster way (because we have approximately 200-300 VMs) and some of them are so big that a live migration is impossible (only an offline migration could be done, resulting in a downtime). Another way to refresh the list is detaching the volume, but this only works for non-bootable volumes. We tried modifying the virsh XML directly (virsh edit ...) and creating a separate XML file and applying it with "virsh define newfile.xml", but the list will not be updated. Many thanks in advance!

2 1

[qa][ops] Light-weight guest image for UEFI boot and secure boot
by Takashi Kajinami 18 Nov '25

18 Nov '25

Hi, I've been trying to implement a few tempest tests to verify functionality of UEFI boot and secure boot, and I noticed that cirros, which is used as a primary guest image for tests, do not support UEFI boot. I'm wondering if anyone can share a good light-weight guest image used in their own tests of these features ? I guess that ubuntu guest image might be a primary choice (given the fact that ubuntu is the default operating system for tests) but I'm wondering if we have more light-weight one. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

5 7

[publiccloud-sig] Public Cloud SIG meeting d.d. 19 November
by Kees Meijs | Nefos 18 Nov '25

18 Nov '25

Hello Stackers, Tomorrow (that's 19 November) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0

[tc][tripleo] About os-net-config
by Goutham Pacha Ravi 17 Nov '25

17 Nov '25

Hello Stackers, I am writing to seek clarity regarding recent activity on the PyPI project for os-net-config [1]. As you can tell, "OpenStack" is still listed as the author/maintainer of this package. "os-net-config" was retired early last year along with the rest of the TripleO project within OpenStack's governance [2]. It appears that development has continued outside of OpenStack with the project being forked [3]. There have been releases that were uploaded to PyPi since. A human maintainer was added to PyPi this week. There may be some rationale to continue to maintain this code. Since the project was officially retired from OpenStack, we need to ensure that any renewed activity is properly communicated; and the author/maintainers are properly attributed. For one, "OpenStack" can't be the Author/Maintainer of a project that's not officially under OpenStack Governance. There are references to the OpenStack Documentation Website, TC Badges and IRC/bug tracker links that may now be obsolete and must be removed. This could be confusing to past, current and future users of the project, not to mention the security implications and responsibility attribution on code that's used in systems worldwide. Can the current maintainers please engage with us to make the necessary changes? You can do so here, or chat on #openstack-tc on OFTC. Thanks, Goutham Pacha Ravi [1] https://pypi.org/project/os-net-config [2] https://review.opendev.org/c/openstack/governance/+/905145 [3] https://github.com/os-net-config/os-net-config

4 4

[neutron][openvswitch] NAT + AFS = Sadness
by Jonathan Proulx 17 Nov '25

17 Nov '25

HI All, CERN may be the only other people doing anything with AFS hopefully this catches someone's eye who will just know.... The AFS filesystem use a rather "unique" connection oriented UDP protocol https://docs.kernel.org/networking/rxrpc.html This is where all our user home directories live so at's a key requirement for us. In my production cloud (mitaka sadly) we use direclty routable fixed IPs by default and all is well. In test (epoxy) we want to move away from the public v4 default IPs and lean more on floating ips for public addressing. Testing this I found impossibly poor performance for AFS behind NAT (with or without floating IP in front) on both Mitaka and Epoxy (both using openvswitch and DVR). This isn't a general NAT issue as I and others can use AFS from our homes behind comsumer NAT boxes of various sorts, and stand alone VMs out side OpenStack behind iptables based NAT are also fine. tcpdumping the connection on the fileserver sees strings of ICMP unreachable messages from the OpenStack router address (or floating ip if attahced) mid conversation. My guess is that the NAT is not maintianing stable enough port mapping becuase of the generally true assumption that UDP is stateless and will work itself out. I'm not really deeply familiar with using openvswitch for NAT as seems to be happening. Is there something I can look for in the flow rules to see what's going on? Can I tune anything to make the mappings more stable (assuming that's the issue) or am I just going to need to keep the old architecture that works? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-19)
by Goutham Pacha Ravi 17 Nov '25

17 Nov '25

Hello Stackers, We're nineteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Last week was Milestone 1 of this release, which project teams used to track features and bug fixes; it also served as an opportunity to ship some incremental releases across various deliverables [2]. Following up from the Project Teams Gathering, the OpenStack Technical Committee is working on Special Interest Groups within the community. The goal is to identify SIGs that need help, combine efforts, and clean up cruft in our documentation. Historically, SIGs were under the combined purview of the OpenStack Technical Committee and the OpenStack User Committee. Since these governance bodies merged in 2020, it's time to achieve more while doing less. We are combining the "governance-sigs" repository with the "governance" repository, and then auditing the SIGs and updating other outdated governance information. I encourage you to view the current SIGs [3], and if you're interested in joining an active SIG, or reforming an inactive one, please do let us know via this mailing list, or by joining the #openstack-tc IRC channel on OFTC. === Weekly Meeting === The TC met over IRC on November 11th, 2025 [4]. We followed up on action items from the recent Project Team Gathering (PTG). We added tasks to our backlog to analyze the 2025 User Survey results, and to rework the FIPS Compliance goal around testing and objectives. A new action item was assigned to clarify and document the TC's policy regarding AI/LLM contributions through the Project Team Guide. We discussed the retired project, os-net-config. The project's maintainers have removed OpenStack CI and fixed the author metadata on PyPI, as was flagged in a discussion on this mailing list [5]. There was some concern that this was problematic as it could mislead users into installing non-OpenStack-governed code without knowledge that this governance change had occurred. The consensus was that while it might be too much effort to force a PyPI name change, the TC would draft a formal resolution to retroactively acknowledge the project's handover and focus efforts on locking down PyPI access for any remaining OpenStack projects to prevent similar uncoordinated takeovers. I'll keep you posted regarding this. Wrapping up, OpenDev administrators announced the successful completion of Debian Trixie mirroring in the CI, making a DevStack job available for project teams to test with. The next meeting of the OpenStack TC is today, November 18th, 2025 at 0800 UTC. It will be hosted via IRC on OFTC's #openstack-tc channel. Please find the meeting's agenda and other details in the meeting's wiki page [6]. Please note that the TC has begun hosting a monthly meeting at this new time so we can encourage participation from folks in APAC countries. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Merge governance-sigs repository into governance | https://review.opendev.org/c/openstack/governance/+/966644 ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-12-04: 2026.1 release deadline for "cycle-trailing" projects - 2026-01-08: 2026.1 Milestone 2 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] Milestone 1 releases: https://review.opendev.org/q/topic:%22gazpacho-milestone-1%22 [3] OpenStack Special Interest Groups: https://governance.openstack.org/tc/reference/sigs/ [4] TC Meeting IRC Log, Nov 11th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-11-17.01.html [5] os-net-config: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Nov 18 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[OSSA-2025-002] OpenStack Keystone: Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization (CVE PENDING)
by Jeremy Stanley 17 Nov '25

17 Nov '25

========================================================================= OSSA-2025-002: Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization ========================================================================= :Date: November 04, 2025 :CVE: PENDING Affects ~~~~~~~ - Keystone: <26.0.1, ==27.0.0, ==28.0.0 Description ~~~~~~~~~~~ kay reported a vulnerability in Keystone’s ec2tokens and s3tokens APIs. By sending those endpoints a valid AWS Signature (e.g., from a presigned S3 URL), an unauthenticated attacker may obtain Keystone authorization (ec2tokens can yield a fully scoped token; s3tokens can reveal scope accepted by some services), resulting in unauthorized access and privilege escalation. Deployments where /v3/ec2tokens or /v3/s3tokens are reachable by unauthenticated clients (e.g., exposed on a public API) are affected. Patches ~~~~~~~ - https://review.opendev.org/966073 (2024.2/dalmatian(keystone)) - https://review.opendev.org/966067 (2024.2/dalmatian(swift)) - https://review.opendev.org/966071 (2025.1/epoxy(keystone)) - https://review.opendev.org/966064 (2025.1/epoxy(swift)) - https://review.opendev.org/966070 (2025.2/flamingo(keystone)) - https://review.opendev.org/966063 (2025.2/flamingo(swift)) - https://review.opendev.org/966069 (2026.1/gazpacho(keystone)) - https://review.opendev.org/966062 (2026.1/gazpacho(swift)) Credits ~~~~~~~ - kay (CVE PENDING) References ~~~~~~~~~~ - https://launchpad.net/bugs/2119646 Notes ~~~~~ - While the indicated Keystone patches are sufficient to mitigate this vulnerability, corresponding changes for Swift are included which keep its optional S3-like API working. - MITRE CVE Request 1930434 has been awaiting assignment since 2025-09-24, but once completed will result in an errata revision to this advisory reflecting the correct CVE ID. If any other CNA has assigned a CVE themselves in the meantime, please reject it so that we don't end up with duplicates. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

2 2

Approaches to Making Big Changes Within Our Community
by Clark Boylan 17 Nov '25

17 Nov '25

Hello everyone, There seems to be a recent sentiment within the community that the policies we've built to guide OpenStack development processes are unwieldy simply by existing. Any bureaucracy is bad by default and we should feel free to ignore it. I'd like to reject that premise and redirect some of that energy towards (what I think) is a more positive approach to making change. OpenStack has policies and procedures because it is a loose collective of many individuals and companies working towards some rough common goals. Namely the construction of a suite of software tools that interoperate to provide infrastructure as a service services. That is an incredibly broad set of goals and if we let every individual or subproject tackle this problem independently without any guidelines or constraints it would be pure chaos. Instead, over time we've built rules to help reduce the size of the problem space as we've run into fragmentation or problems that pose unnecessary overhead. For example we currently expect software to largely be written in Python, Javascript, or Go. We support Linux as the runtime platform. But we go further and list specific Linux distros that we're actually going to bother testing on. We dropped PostgreSQL support because even that was too much overhead when compared to MariaDB and MySQL. Python test tooling is currently expected to use a standard compliant test runner. Each of these examples are motivated by specific goals. Focusing on specific programming languages gives us consistency between projects so that if I need to fix a bug affecting me outside of my bubble I should have the tools to do so. Constraining programming languages also helps us build tooling around those languages to ensure that we manage packaging, security patching, translations, etc in an effective manner. Linux is a platform that largely provides all of the underlying dependencies that we need to build an infrastructure as a service system. It does so while also being compatible with our Open Source objectives. We could theoretically support OSX or Windows or FreeBSD but doing so would complicate our software and may require us to build additional tools ourselves. Constraints are good. They limit the scope of the work we have to perform which reduces overhead and hopefully produces a better result. Constraints are also important for our users and operators. Backwards compatibility is a constraint. Being able to upgrade from release X to Y is a constraint. I think the fact that we're here more than a decade after the first release with a sizeable user base is a good indicator that at least some of these constraints have been effective towards our goals. That said as time marches on our choices may no longer be in alignment with our goals and our goals may no longer be relevant. We can and should reevaluate our goals and from there reevaluate the decisions we've made. I think if we approach the process of making changes from this perspective and do so collaboratively as a community we can ensure the health of our software and community going forward. We should also probably try to be more explicit about these decisions and rely less on tribal knowledge or secret cabals. Informed developers should end up making better decisions whatever decisions are made. Finally, it probably is worth noting that this sentiment may be driven as a reaction to a community that is very resistant to change. We should be better about reevaluating our goals and decisions around those goals. Maybe this should become a regular process (either as part of the release cycle, or PTG or just annually)? The world isn't static and while some choices we made a decade ago may stand the test of time many probably do not. Let's be more open to that. Clark

3 2

[Neutron] Bug Deputy Report Nov 10- Nov 16
by Miro Tomaska 17 Nov '25

17 Nov '25

Hello All, Here is Neutron bug deputy report for November 10 through 16 *High:* https://bugs.launchpad.net/neutron/+bug/2131024 - [CI] test_add_manager related failures Rodolfo Alonso already proposed a fix https://bugs.launchpad.net/neutron/+bug/2131540 - OVN agent is not gracefully shutting down Assigned: Rodolfo Alonso *Opinion:* https://bugs.launchpad.net/neutron/+bug/2131087 Discuss with the team if port fixed-ip updates should preserve previous fixed-ips *RFE proposal:* https://bugs.launchpad.net/neutron/+bug/2131072 Neutron should publish access usage for neutron resources. Similar to Cinder volume_usage_audit *Undecided:* https://bugs.launchpad.net/neutron/+bug/2130972 - Show response body on GET enforcement request Undecided but there is already a good discussion with contributors *Incomplete*: https://bugs.launchpad.net/neutron/+bug/2131290 Looks like there is an issue connecting to OVN services... waiting for more info -- Miro Tomaska Senior Software Engineer

1 0

[watcher] Deprecate Prometheus datasource
by Joan Gilabert 17 Nov '25

17 Nov '25

Hello everyone, As discussed during the 2026.1 PTG[1], it was decided to deprecate the prometheus datasource[2] during this cycle, in favor of the aetos datasource[3]. The aetos datasource provides the same functionality as the prometheus one, but with the advantage of multi-tenancy and Kestone-based authentication. Let us know if there are any objections. A patch to deprecate the prometheus datasource is proposed[4]. [1] https://etherpad.opendev.org/p/watcher-2026.1-ptg#L207 [2] https://docs.openstack.org/watcher/latest/datasources/prometheus.html [3] https://docs.openstack.org/watcher/latest/datasources/aetos.html [4] https://review.opendev.org/c/openstack/watcher/+/966672 Regards, Joan Francesc

2 1

[magnum][all] Magnum PTG summary
by Dale Smith 16 Nov '25

16 Nov '25

Hi everyone, thanks to those who joined the Magnum PTG on 28th October. It was held early in the morning for EU, and evening for AU/NZ. Apologies to those who were less likely to make it due to the time slot; please reach out if you'd have liked to join but couldn't and we'll take that into account for the next. Attendees: 9 (6 UK/EU, 3 AU/NZ) Etherpad: https://etherpad.opendev.org/p/oct2025-ptg-magnum The floor was open to discussion topics from the etherpad, and topics were discussed in the order presented. We discussed the current state of drivers, and migration from Heat to CAPI: None planned, rebuild your clusters once CAPI is running. Cluster upgrades after that are easy. Installation of the base Kubernetes system to support CAPI drivers was a topic of interest as Magnum with CAPI drivers is now dependant on having a running Kubernetes cluster and not OpenStack Heat. This is left to deployers, but improved documentation of options and deployers would be helpful. Magnum documentation on docs.openstack.org was brought up and agreed to be in a poor state with out of date and very old references. The consensus was we should **remove** the existing documentation and rewrite it without references to Heat driver (which is deprecated and slated for removal; making this decision easier in G). Older documentation for old releases would still be available on docs.openstack.org. As with the past few cycles, the CI system needing to cover CAPI was raised. mnasiadka is planning to work on this in the G cycle. Eventlet removal patches have been created last cycle, and the core team agrees to push forward with reviewing and merging these early in the cycle so any problems can be found. and finally, discussion on a longer term feature proposals around labels[1][2] was continued with specs linked (which are noted as needing an update to current thinking). The current state of labels in Magnum is in need of an update to support more features of Cluster API; allow end users to modify these labels for a running cluster, discover valid labels, and provide a more structured format for defining these per ClusterTemplate, Cluster and NodeGroup. References: [1] https://review.opendev.org/c/openstack/magnum-specs/+/943358 Propose label normalisation spec. [2] https://review.opendev.org/c/openstack/magnum-specs/+/955549 Add spec for api-validation-with-driver -- DALE SMITH Cloud Engineer Catalyst Cloud <https://catalystcloud.nz> Aotearoa New Zealand's cloud provider e dale(a)catalystcloud.nz w catalystcloud.nz <https://catalystcloud.nz> Follow us on LinkedIn <https://www.linkedin.com/company/catalyst-cloud-limited/> Level 6, Catalyst House, 150 Willis St, Wellington 6011 Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267 <tel:+6444992267>.

1 0

Neutron OVN migration
by Gk Gk 16 Nov '25

16 Nov '25

Hi Folks, I thought of sharing the below post detailing my learnings during the neutron plugin migration from LXB to OVN. Please check this out if anyone is interested. https://medium.com/@ygk.kmr/openstack-neutron-migration-from-linux-bridge-t… Thoughts, comments, opinions are welcome including criticism.. Thanks Kumar

2 2

[release] Release countdown for week R-19
by Thierry Carrez 14 Nov '25

14 Nov '25

Development Focus ----------------- We are now past the gazpacho-1 milestone. Teams should now be focused on feature development and completion of goals [0]. [0] https://governance.openstack.org/tc/goals/selected/index.html General Information ------------------- Our next milestone in this development cycle will be gazpacho-2, on January 8, 2026. This milestone is when we freeze the list of deliverables that will be included in the 2026.1 "Gazpacho" final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/gazpacho directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- gazpacho-2 Milestone: January 8, 2026 -- Thierry Carrez (ttx)

1 0

[Kolla] Transition Antelope (2023.1) to End of Life
by Bartosz Bezak 14 Nov '25

14 Nov '25

Hello, The Kolla Antelope (2023.1) deliverables - Kolla, Kolla-Ansible, Kayobe and Ansible-Collection-Kolla - are being moved to end-of-life (EOL) status. [1] Antelope has been in the unmaintained state for some time, and the Kolla community does not have the resources to support it further. There are no active changes for Kolla project deliverables in the Antelope branches. [2] In line with other OpenStack projects, Caracal (2024.1) will also be marked as unmaintained soon. Dalmatian (2024.2) and Epoxy (2025.1) are currently our supported stable releases. Flamingo (2025.2) is expected to be released in the coming weeks. [1] https://review.opendev.org/c/openstack/releases/+/967217 [2] https://review.opendev.org/q/project:%22%5Eopenstack/(ansible-collection-ko… Best regards, Bartosz Bezak

1 0

Opensearch Service Update
by Daniel Pawlik 14 Nov '25

14 Nov '25

Hello, We would like to notify you that the Opensearch service [1] would be updated to a newer version on 13 November 2025 at 12:00 PM UTC. This procedure might take a while, depending on the cluster size. During that time, the Opensearch service would not be available. If anyone has any doubts, please reply to the email. Dan [1] - https://opensearch.logs.openstack.org/_dashboards/app/home

2 2

[neutron] Drivers meeting canceled Friday, November 14th
by Brian Haley 13 Nov '25

13 Nov '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meeting as I will be out. Just a reminder that our open spec list at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[OpenStack Ansible] [Deployment] Networking design issue
by holywine＠outlook.com 12 Nov '25

12 Nov '25

Hello, [Following up a previous unfinished case/task with an enhanced network] I am trying to build a minimum usable production-level cloud with OpenStack Ansible following online reference. (https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/) openstack-ansible version: stable/2025.1 4 servers as target hosts, all with Ubuntu 24.04LTS. Each server has two Ethernet ports enp11s0f0, enp11s0f1. All servers’ enp11s0f1 ports has a fixed public IP (10.2.46.XX/24) and has access to Internet. All servers’ enp11s0f0 ports are intended to be used for OpenStack traffic. They are assigned IP range in 172.29.XX.XX for internal use. The idea of design: 1) Infra1: Controller 1 + networking 1 2) Infra2: Controller 2 + networking 2 3) Compute 1: Compute 1 + networking 3 + storage 1 4) Compute 2: Compute 2 + networking 4 + storage 2 Reference: The network topology and the deployment configuration (including user_variables.yml and openstack_user_config.yml) for a trial run can be found: https://github.com/holywi/git-tutorial/tree/master While, with this setting the deployment always failed by reporting errors seems to be related to HAproxy. I am wondering it is related to network design and services assignment. It would be grateful if anyone can provide some comments, suggestions or some common practices for the similar case. Some questions have popped up in my mind: 1) Does it make sense to make each host to access Internet on its own? It seems possible since each server has dedicated port and Openstack can support local routers? If not, how can these servers access Internet? 2) Is it good to make all 4 hosts the HAproxy server? 3) If using an FQDN for internal_lb_vip_address (it seems to be the case in the reference config) where the DNS server is located and how to make it happen? I don't see any setting which is related to DNS and DHCP which seems to be useful as well. Highly appreciate for any feedback as a new comer for Openstack.

1 0

OpenStack Student Engagement, University Partnerships, & Mentors
by Kendall Nelson 12 Nov '25

12 Nov '25

Hello Everyone, You might have noticed a non zero number of my emails to the mailing list have to do with the University Partnership Program <https://openinfra.org/university-partnership-program/> and engaging with universities to get students involved in OpenStack (and generally open source). Usually these emails are per university/opportunity which is rather inefficient and all too often I end up being a bottleneck in the process. At the PTG, during one of the Technical Committee sessions I shared an etherpad <https://etherpad.opendev.org/p/UPP-Projects%26Mentors> that I am hoping to utilize to smooth the whole process. The intent is to collect possible projects up front that I can share with professors as they reach out to me. I take responsibility for regularly auditing the project list so it doesn't become stale. Potentially this collection + audit could be a PTG session at future PTGs, but that doesn't have to be decided now. You will notice in the etherpad, that I also have a place for just collecting folks interested in being mentors. If you don't currently have an idea for a project, but are interested in mentoring, please add your name to that section. This list will also get regularly refreshed, but I am thinking on a yearly basis instead of twice a year - that said, nothing is stopping you from adding or removing your name in between those audits. I am 100% open to feedback on this, but it will hopefully allow more folks interested in participating in the University Partnership program and help smooth out the process for involvement. If you want to get involved either as a mentor or with a specific project proposal for students, please add to the etherpad ASAP <https://etherpad.opendev.org/p/UPP-Projects%26Mentors>! I expect a round of professors reaching out in the next month for students starting their terms in early January (usually running through late May). Please let me know if you have any other questions I might have missed. And thank you to everyone that made it through this lengthy email :) -Kendall

1 0

[all][keystone] Keystone PTG summary
by Artem Goncharov 12 Nov '25

12 Nov '25

Hey guys Let us give you an update of the OpenStack Keystone future following the great PTG week we just had. Some news has already spread across the community, causing excitement and anxiety. It is not uncommon that changes cause fear. Some time ago, in the age of the Inquisition, people were even burned because of fear, misunderstanding, or questioning the rules. Let us clarify things. Nearly 13 years ago, the Identity v3 API was introduced. Since then, the world has changed dramatically. Libraries we use got abandoned, standards went legacy and replaced with new ones, ecosystem components, certain functionality is based upon are being sunsetted by OS vendors (mod_auth_mellon is archived upstream and gone in CentOS and RHEL [6]), new security vulnerabilities (classes of vulnerabilities) appear like mushrooms without us being able to address them. Cloud providers today face new challenges that were not present 10-15 years ago. Nowadays, a public cloud requires proper federation support with complete self-service. Users request passkey support, and security departments require additional hardening. These things cannot be covered in today's Keystone architecture and API version. As a result, work on an optional extension to Keystone [1] began some time ago, allowing CSPs to deploy it in parallel with the Python Keystone (of any v3 version) and access the new features. To simplify parallel deployment, it has been decided to start introducing v4 with the new features (since those ARE for cloud end-users). The work was done in Rust due to multiple factors: lack of necessary python libraries with trustable maintenance and/or licensing, necessity for enforcing security standards and practices using memory safe programming language, demand to address python ecosystem madness of past years (I guess majority would agree, that in the past few years we were mostly only chasing the python ecosystem breaking us on setuptools, eventlet, passlib, …). During the work, it became clear that implementing the mentioned features requires support of a given percentage of the existing functionality: users, groups, projects, roles, and tokens. And so it was implemented. A side effect of it became immediately visible: performance. Token check is THE most frequently called API in the OpenStack cloud. Right now, caching is used to reduce system stress. But in Rust, token decryption, without caching, is much faster than in python with caching (we expect a 2-3x faster order of magnitude). As mentioned above, new vulnerability classes and attack vectors require us to disable caching, making such an improvement highly valuable. The new stack is fully async, uses parallel DB queries, and runs background tasks for periodic cleanups, synchronization, and similar. This allows us to achieve significant performance and maintainability improvements, eliminate the old ballast, and significantly reduce transitive dependency version conflicts. Current measurements also indicate that we would likely be able to eliminate the need for caching in Keystone. For python, on the other hand, we do not have much to start with and would need to find and migrate to the new web framework, find maintained libraries with suitable licenses, and implement new features. We also need to rework the DB access patterns due to the number of bugs and the performance penalty caused by suboptimal DB access (many rows are selected multiple times during processing of a single request). With new authentication flows, we would need to do a wide security assessment of Keystone from scratch anyway. With that work in mind and facing the prospect of having a major rework in python Keystone anyway (due to the abandoned complex dependencies), we, as the Keystone team, decided to try to focus the work on the Rust implementation, making it a proper evolution of the python Keystone and building a necessary community around it. This adoption is conditional on adding new contributors to support the project. We believe this approach allows the best of both worlds: the trusted maturity of Keystone’s Python code-base, combined with the modern, high-safety, high-performance capabilities of Rust where they matter most. Logically, this raises questions, so let's try to answer some of them: 1. Rust is not officially allowed in OpenStack. How are you dealing with that - The development is now going on on GitHub outside of OpenStack governance. - We would apply for OpenStack universe inclusion. - Once the TC policy allows Rust or the overall project inclusion requirement is reworked, the project will work toward becoming the official OpenStack project. - No one in the team is willing to separate from OpenStack, but with the current policies, we have no other way. Everybody and everything in the OpenStack ecosystem would benefit from that project being official to have first-class native support of the new functionality. - Multiple CSPs expressed support for such a move, desiring to see Rust in the ecosystem for better performance, maintainability, and resource utilization - A nice coincidence is a freshly sent announcement from Debian that introduces a strong rust dependency in the packaging tooling, stating something similar to: either you work to comply with this requirement in the next 6 months or sunset the port [5]. - Rust allows cross-integration with python with a high number of cryptography and typing libraries for python written directly in Rust. We are going to be able to reuse certain pieces of python in Rust during porting and Rust in python later in the future. - Keystone is a very sensitive component and in our eyes that fully justifies use of rust to provide a much stronger security on the language level. 2. Do you deprecate python Keystone. - No - v3 is there, and we continue maintaining it - We would unlikely accept major changes - Keystonemiddleware, keystoneauth, etc, are still there. They would likely be adopted for v4 support at some point in the future (in OpenStack services, we already communicate with “external” software, so there should be no problem). Those libraries are crucial for other services and thus are there to stay while necessary. - At some point, we will no longer be able to keep it alive when abandoned dependencies are physically gone. We are not going to invest our time in maintaining the abandoned software; we do not have enough time to do so. 3. What is the community around it? - As of now, there are provisional commitments from a few vendors and CSPs to collaborate on it. - Existing software is being transferred under the openstack-experimental organization to help build the community [3]. -The initial author (gtema) personally commits to continue working on that independently of others. 4. What are the /v3 features that would go away? - OIDC federation in its current form. v4 reimplements it from scratch natively without depending on external software (mod_auth_oidc, etc) since those make self-service impossible. - Saml2, this is a legacy protocol that is very unlikely to even get fixes for security vulnerabilities, and looks to be PQC unsafe. - Oauth1. 5. What new features are there in v4? - OIDC with self-service and CLI integration - Workload federation (Zuul, GitHub, Gitlab do not need to have secrets to access OpenStack anymore) - Service accounts (many use cases, one of the prominent ones: OpenStack on Kubernetes, GitHub workflow) - Passkeys (webauthn) - SCIM - Tight Open Policy Agent integration. We plan to consider the reintroduction of central policy storage in Keystone (not enforcing, but for central storage)[4] We will use the next 2-3 months to gather interest in contributing to this approach and the new Rust-based code. There was a lot of interest in the new features listed right above during gtema’s sessions in OpenInfra Summit in October 2025. Still, it has to translate into active contributors for this effort to take off. If you have an interest in those new features, join us! We hope this clarifies the situation. Feel free to reach out with other questions. Thanks to everybody who participated in the discussions. Regards, Keystone team [1] https://github.com/gtema/keystone [2] https://www.youtube.com/watch?v=XOHYqE2HRw4&list=PLKqaoAnDyfgr91wN_12nwY321… [3] https://github.com/openstack-experimental/keystone [4] https://www.youtube.com/watch?v=_B4Zsd8RG88&list=PLKqaoAnDyfgr91wN_12nwY321… [5] https://lists.debian.org/debian-devel/2025/10/msg00285.html [6] https://access.redhat.com/solutions/2743391

10 20

[oslo][all] Proposing oslo.wsgi
by Stephen Finucane 12 Nov '25

12 Nov '25

o/ I'd like to propose the creation of a new "oslo.wsgi" project that service projects should adopt, where it makes sense to. My reasons for this proposal are three-fold: * As we've been working on the OpenAPI work for various services, we've found ourselves copy-pasting a lot of the code between these services. This has occasionally led to issues when those copies are incomplete [1][2]. Historically speaking, copy-pasting of code between services is a sure sign that this code should be generalised and placed in an oslo library * I have previously noted [3] that oslo.service contains some non- eventlet-related WSGI routing code, and there are questions around whether (a) that code should have been placed there in the first place and (b) how we can maintain that long-term once the eventlet code is removed (the 'oslo_service.wsgi' module has side effects since it imports the backend configuration stuff). * I have also raised some concerns around our use of paste.deploy and routes [1], both of which are minimally maintained nowadays. Many oslo libraries are designed to abstract their underlying libraries, allowing users to switch between e.g. different messaging backends (oslo.messaging) or caching services (oslo.cache). Taken together, I think now would be a good time to provide a new library. I have an initial prototype available [4] which is effectively just a refactoring of the code from oslo.service, but I expect to add both more functionality to this existing code from existing consumers (Nova, Manila, Cinder etc.) and to add the openapi validation machinery. I imagine longer-term, this should evolve to allow us to replace the underlying libraries. However, we should obviously not get into the business of writing our own web framework. I also don't think it would make sense for all services to adopt all aspects of this project, since not all projects have any OpenAPI efforts ongoing at the moment and not all of them use the pastedeploy-routes-webob combo. Given the above rationale and caveats, what do people think? Are there any objections to this idea? Please let me know. If there is not, I will go figure out how to get the ball rolling on this. Cheers, Stephen PS: Why oslo.wsgi instead of a more generic name like debtcollector or futurist? I don't think this library will be useful outside of OpenStack, so the oslo prefix makes sense. [1] https://review.opendev.org/c/openstack/ironic/+/963938 [2] https://review.opendev.org/c/openstack/ironic/+/960291 [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] https://github.com/stephenfin/oslo.wsgi

8 13

[watcher] 2nd call for maintainers - MAAS integration
by Douglas Viroel 12 Nov '25

12 Nov '25

Hi all, The Watcher team had a session[1] during the last PTG about the impacts of service integrations that have lacked maintainers, documentation, and/or testing coverage in CI. The MAAS (Metal As A Service) integration still lacks maintainers and is impacting the eventlet removal effort within Watcher, since it contains eventlet-dependent code that requires maintenance and validation. In the 2025.2 development cycle, we had a first call for maintainers[2] and we didn't receive any feedback. This is a second call for maintainers interested in supporting MAAS in Watcher, to help fill these gaps (eventlet removal, CI testing, documentation). The Watcher team plans to *deprecate* this integration during the 2026.1 cycle if we don't find anyone to assist in maintaining it. [1] https://etherpad.opendev.org/p/watcher-2026.1-ptg#L177 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… Thanks and regards, -- Douglas Viroel - dviroel

2 1

[Kolla-Ansible][Tacker] [VIM]Unable to find key file for VIM
by josem.arco＠uah.es 12 Nov '25

12 Nov '25

Hi All, I have installed an bare-metal server Ubuntu 24.04 with Kolla-Ansible and all-in-one with Tacker. When I register the OpenStack Vim with the CLI I have this error “Unable to find key file for VIM e255b2e2…”. I have tried with the two optios of the 'cert_verify' parameter but it doesn’t work. I have also tried to do it with Horizon and it says “Error: Failed to register VIM. Details The request you have made requires authentication.” I have followed the lastest web pages of Kolla and Tacker. Thanks in advance for your help. Jose

1 0

Add Trait requirement to running Instances
by Kees Meijs | Nefos 12 Nov '25

12 Nov '25

Hi list, We're looking for a method to add Trait requirements to already running Instances, forcing certain placement upon resize or migration of them. Is there a clean way to do this? Or is there database surgery (which is acceptable to some extend) needed, and how? Thanks! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

2 2

[all] PSA: requirements-check job no longer normalises underscores with hyphens
by Stephen Finucane 12 Nov '25

12 Nov '25

o/ Sean Mooney noted earlier today that watcher's requirements-check job has started failing with the following warning: Validating requirements.txt WARNING: possible mismatch found for package "microversion_parse" Attribute "package" does not match "microversion_parse" does not match "microversion-parse" Requirement(package='microversion_parse', location='', specifiers='>=0.2.1', markers='', comment='# Apache-2.0', extras=frozenset()) Requirement(package='microversion-parse', location='', specifiers='', markers='', comment='# Apache-2.0', extras=frozenset()) ERROR: Could not find a global requirements entry to match package microversion_parse. If the package is already included in the global list, the name or platform markers there may not match the local settings. This is almost certainly due to recent changes in the openstack/requirements repo to remove use of the soon-to-be-removed pkg_resources library [1]. Its replacement for this use case - packaging - does normalisation slightly differently and it seems it doesn't replace underscores with hyphens. While this could be fixed with custom normalisation in the requirements repo, I don't believe it's wise to do so as that custom normalization would need to be copied anywhere else that needs to parse OpenStack requirements.txt files and requirements more generally. I would instead encourage affected projects to fix the names used in their various requirements.txt files and use the correct PyPI names. From a quick look at failing requirements-check jobs in recent days [2], there aren't many: I see neutron has already fixed the issue [3] and I've proposed a fix for tap-as-a-service [4]. Those patches should prove how small a task this should be. Hope this helps, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/960845 [2] https://zuul.opendev.org/t/openstack/builds?job_name=requirements-check&res… [3] https://review.opendev.org/c/openstack/neutron/+/965188 [4] https://review.opendev.org/c/openstack/tap-as-a-service/+/966782

2 1

List Limits returns Null in Nova Unified Limits
by Tyler Wilson 11 Nov '25

11 Nov '25

Hello All, I'm looking into testing out the Nova unified limits, however I am experiencing an odd issue where the 'limit list' returns no data. The 'limit create' and 'limit show' (with the UUID from the create command) seem to work fine. Paste data for the output is here: https://pastebin.com/sPZgZDEK I've even tried sending a GET to http://KEYSTONE_IP:5000/v3/limits with the output of [] ({"limits": [], "links": {"next": null, "self": "http://KEYSTONE_IP:5000/v3/limits", "previous": null}}) The log in keystone WSGI just shows a 200 for the GET request, not much else I could find. Should this work in the way I am expecting here? Or am I missing something? Thanks for any and all assistance!

2 5

[cinder][PTG] 2026.1 Gazpacho PTG summary
by Jon Bernard 11 Nov '25

11 Nov '25

Hello everyone, thanks for a very productive PTG for the Gazpacho cycle. Below is a brief summary of the highlights. The raw etherpad notes are here [1] and both the summary and transcribed etherpad notes are captured in out wiki here [2]. # Retrospective We spent time discussing the good and not-so-good of the flamingo cycle. Unsurprisingly, code reviews continue to be our most significant opportunity for improvement. We reviewed what a core reviewer is and how to work towards becoming one, including the metrics that we use to determine eligibility and what we look for in a potential core reviewer. I encourage anyone interested in contributing the project to reach out, in addition to our guideline document on the review process, we're happy to answer questions and help guide folks through the process. # Festival of Reviews We are reworking our 'festival of reviews' meeting to better accommodate a larger set of potential patches. Previously it focused on very small patches that were easier to review, but feedback suggests that time spent as a team on larger reviews would yield a more desirable result. Last Friday we ran the modified format and it seemed to work quite well. # 3rd Party CI This cycle 3rd party CI is required for patches to be reviewed. In the flamingo cycle we saw some challenges with deploying and configuring the software factory setup required to operate a CI. We remain committed to helping vendors sort out any remaining problems, and want to avoid any further slipping on our requirements, as one-off exceptions do not scale. # Eventlet Removal There will be significant focus this cycle on the removal of eventlet from our codebase. Our goal is to have this work completed before M2. The remaining issues and technical challenges were discussed, including some struggles with our multi-backend and it's use of sqlalchemy. We learned that the oslo team is working on some code that may help with this effort. We may have finally found a use for the rally job, unfortunately it has been broken for some time, we will try to get this fixed and reporting useful results this cycle as well. # Driver Block Geometry An original patch to the RBD driver was proposed to make configuring block geometry an option for the operator. Upon inspection, we decided make this option available for all drivers. Discussion about exact location given out driver class model, we have a way forward. https://review.opendev.org/c/openstack/cinder/+/658283 # Per-Tenant SVM Creation Doug Goldstein showed up and blew our minds with a proof-of-concept feature he added to the NetApp driver. This change allows the driver to create per-tentant SVMs and map them to dynamically created backends. There will be some technical hurdles to overcome, but the idea in theory could work. Doug is going to work to propose a patch upstream and with the NetApp team to see if it can take shape. # OpenAPI Stephen has had patches up for openAPI compliance for far too long. We don't have any technical objections to the effort. Brian and I committed to working through the proposed patches at the very start of the cycle. Significant progress already, should be completed soon. # Reverting To Any Snapshot Currently you can only roll a volume back to the last available snapshot. We would like to be able to select any snapshot as a rollback target. Technical requirements were discussed, including the need for a spec. Hoping to see progress on this effort in this cycle. # Clone Across Pools We are interested in improving our implementation for cloning a volume across different pools. The code itself has some distinct shortcomings and Rajat identified several opportunities for improvement. Feedback on current usage was requested, we discussed volume caching as part of these improvements. A path forward was defined and spec should follow. # NFS Driver Feedback Fernando has been working on several improvements to the generic NFS driver and requested feedback. NetApp offered valuable suggestions, some improvements to our tempest testing patches are forthcoming, and a direction forward is understood. # Replication Feedback We solicited feedback on replication, its current usage, and the features it may require to see wider adoption. Questions and answers were discussed, hoping to see a spec capturing the most valuable changes in this cycle. [1] https://etherpad.opendev.org/p/cinder-gazpacho-ptg [2] https://wiki.openstack.org/wiki/CinderGazpachoPTGSummary -- Jon

1 0

[ironic] [all] Ironic PTG Summary
by Jay Faulkner 11 Nov '25

11 Nov '25

Hi all, The Ironic team had another successful PTG planning our 2026.1 release. As usual, we've published a summary of the discussions into the work items document we'll be referencing throughout the year. https://specs.openstack.org/openstack/ironic-specs/priorities/2026-1-workit… If you'd like more in-depth detail as to discussions, please review the etherpad for the PTG at https://etherpad.opendev.org/p/ironic-ptg-2026.1 -- everyone is also welcome to respond here or come join us in OFTC #openstack-ironic to discuss any of these items if needed. Thanks, Jay Faulkner G-Research OSS

2 2

[PTG] Call for Summaries, Attendance Numbers, and Team Photos
by Kendall Nelson 10 Nov '25

10 Nov '25

Hello Folks! I am working on a summary post for our OpenInfra Blog as usual and I am missing A LOT of attendance numbers from OpenStack teams. Specifically, I am missing attendance numbers from: - Barbican - Blazar - Cinder - Cloudkitty - Cross Deploy - Designate - Eventlet Removal - Glance - Heat - Horizon - i18n - Ironic - Keystone - Kolla - Magnum - Neutron - OpenStack Ansible - OpenStack Helm - Sunbeam - Swift - Tacker - Telemetry - Watcher If you were a moderator for this session please send me your approximate attendance to ptg(a)openinfra.org ASAP. If you simply attended one of these sessions, and you would be so kind as to remind the moderator to send me the info I would be very grateful! Additionally, I will happily accept any team photos that were taken and links to blog posts or other summaries that I can include in OpenInfra Blog post as well. There are a lot of open source communities outside of the OpenInfra Foundation that are curious about how we conduct our PTGs and these posts are incredibly helpful at educating others on how to follow the four opens and build a stronger community. Thank you for all of your support! Looking forward to the next PTG! -Kendall

2 3

[nova]Migrating instances with anti-affinity rules causes them to enter ERROR state
by Nguyễn Hữu Khôi 10 Nov '25

10 Nov '25

Hello, I have two instances of an anti-affinity rule. When I move instance a to the host which contains instance b then instance a enters error state. It will be nice if we keep instances at source compute and notify. My env: Openstack 2025.1 Ubuntu 24.04 Nguyen Huu Khoi

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-21)
by Goutham Pacha Ravi 10 Nov '25

10 Nov '25

Hello Stackers, We are twenty-one weeks away from the date of the coordinated release of OpenStack 2025.2 "Gazpacho" [1]. Next week is Milestone-1 of the release. This is typically a bug and feature tracking milestone for project teams. Hope you have been catching up on all the post-PTG action from the past week on this mailing list and on IRC. The OpenStack Technical Committee's PTG summary was shared as well [2]. We are hoping to check on the pending items through our weekly meeting. In the past week, the Telemetry team welcomed back Juan Larriba (jlarriba) as its PTL for the current release cycle. There have been no other governance updates from the OpenStack Technical Committee to report, however, we are looking to close out a long list of pending changes to fully retire the Monasca project [3]. === Weekly Meeting === The last weekly meeting of the OpenStack TC occurred on November 4th 2025 in the #openstack-tc channel on OFTC [4]. It was quite brief since we were still recovering from all the sync meetings from the Summit and the PTG week. We covered the follow-up from the awesome APAC/EU-friendly TC meeting and realized we need to nail down some owners for the user survey action items that we took. We noted that the deadline for getting new questions in for the next survey is December 1st 2025. We had a good discussion about tracking and preserving project PTL appointment history on the governance repository. On the CI front, we hit a brief Gerrit outage, likely caused by an OOM issue that one of our generous providers, Vexxhost, was looking into. OpenDev administrators were working through a Zuul bug that is causing multinode jobs to jump between providers. We also noted the transition of the "stable/2024.1" branch to "unmaintained/2024.1" - this transition affected all repositories that contained the stable/2024.1 branch. A link to a discussion on the CRA (Cyber Resilience Act) was shared [5], with a prevailing interpretation being that individual open source contributors/maintainers have no legal obligations under it. Overall, this was a light meeting, but things are about to get heavy once we digest all the PTG takeaways. The next meeting of the OpenStack TC is on November 11th 2025 at 1700 UTC. It will be hosted on the #openstack-tc channel on OFTC. The agenda for this meeting is on the meeting's wiki page [6]. I hope you will be able to join us. === Governance Proposals === ==== Merged ==== - Propose jlarriba to Telemetry PTL | https://review.opendev.org/c/openstack/governance/+/964516 ==== Open For Review ==== - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-11-10: KubeCon NA: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america - 2025-11-15: Celebrating 15 years of OpenStack, Montréal: https://www.meetup.com/montreal-openstack/events/310374679/ - 2025-11-15: KCD + OpenInfra Days, Hangzhou: https://sessionize.com/kcd-hangzhou-and-oicd-2025/ Thank you very much for reading On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack TC PTG Summary: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Monasca Retirement: https://review.opendev.org/q/hashtag:%22monasca-retirement%22+(status:open%… [4] TC Meeting IRC Log, Nov 4th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-04-17.00.html [5] CRA update: https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.… [6] TC Meeting Agenda, Nov 11 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic] Proposed: Reviewer & Approver team updates
by Jay Faulkner 10 Nov '25

10 Nov '25

Ironic approvers had a discussion about the current state of the core team, and we propose the following changes. As some context for those not familiar, Ironic has two review groups: - Ironic-Approvers -- this group has the ability to +2 changes and Workflow +1 changes - Ironic-Reviewers -- this group has the ability to +2 changes, but cannot Workflow +1 changes I am proposing the promotion of our two inaugural members of ironic-reviewers into approvers. Both of these contributors have used their +2 judiciously and have earned the trust of the community to use that same judgement about which changes to approve: * Afonne-CID (cid) from GR-OSS (move from ironic-reviewer to ironic-approver) * Doug Goldstein (cardoe) from Rackspace (move from ironic-reviewer to ironic-approver ) Additionally, we'd like to add an existing community member to ironic-reviewers. Jakub Jelinek has become the community expert on RAID support in IPA and has deepened his knowledge across the codebase. We'd like to recognize that by asking him to join the ironic-reviewers team. * Jakub Jelinek (kubajj) from CERN (add to ironic-reviewer) Finally, we would like to move an existing ironic-approver and longtime contributor to emeritus status. Mark Goddard is no longer active in the OpenStack community, and I propose he be moved to emeritus status. This just means that while he may be removed from the team, if at some future point he returns to the Ironic community we may expedite his return to the approvers group. * Mark Goddard (remove from ironic-approvers) Thanks everyone for your contributions to Ironic, current and future. It's nice to see the growth of the team, and hope this opens the door for CID, cardoe, and kubajj to grow themselves and the team further. Thanks, Jay Faulkner G-Research OSS

4 4

[Nova] Spec Soft Freeze Approaching November 20!
by René Ribaud 10 Nov '25

10 Nov '25

Hi everyone, Time really flies, we’re already approaching the Nova Spec Soft Freeze for the Gazpacho cycle! Just a quick reminder that after November 20, 2025 (23:59 UTC), no new specs will be accepted. If you’re currently working on a proposal or reviewing one, now’s the time to propose it. Let’s make the most of the remaining days, and thank you all for keeping the momentum going! Cheers, René

1 0

[openstack-ansible] Bug fighting day - Save the date
by Dmitriy Rabotyagov 10 Nov '25

10 Nov '25

Hi everyone, This week, on Thursday, *November 13*, we are going to hold our yearly bug-fighting day. We plan to start active work around *1:00 PM UTC*. The activity aims to gather all Core Reviewers along with interested community members to join forces to review, triage and propose patches to as many bug reports as possible. This should contribute towards project stability and reduce the amount of issues in the project codebase. We invite everyone interested to participate to join our #openstack-ansible IRC channel on OFTC network. Alternatively, you can join the room #_oftc_#openstack-ansible:matrix.org with your Matrix (Element) account. We are going to use an Etherpad [1] to work in an asynchronous way and to ensure that different people will not be working on the same bug reports. Please sign in in the Etherpad [1] participants list before starting the work, so we could estimate participation and scope we can pull during the day. [1] https://etherpad.opendev.org/p/osa-nov-2025-bug-triage

1 0

[openstack-ansible][ptg] 2026.1 Gazpacho Summary
by Dmitriy Rabotyagov 10 Nov '25

10 Nov '25

Hi everyone. OpenStack-Ansible team has held a PTG session, where discussed left scope before 2025.2 (Flamingo) Release as well as development scope for 2026.1 releases. For 2025.2 we agreed to finalize these topics: - Debian 13 (Trixie) support - Fix playbooks to address ANSIBLE_GATHER_SUBSET removal in ansible-core 2.18 - Finalize OpenBao backend for the PKI role As I am writing a summary late this time, 2 out of 3 topics (Debian 13 support and ANSIBLE_GATHER_SUBSET replacement) have already been concluded. With that being said, we move couple of topics to 2026.1 (Gazpacho) cycle, specifically: - Mainstreaming Magnum CAPI drivers (promoting from ops repo to the integrated one) - Molecule coverage for the HAProxy role For the 2026.1 (Gazpacho) release cycle, the following topics were raised: - Improving MariaDB proxying and introducing read/write balancing. Originally we agreed to adopt ProxySQL, as we had plans for that since the Xena release, but it was never prioritized. Now we've realized that there is a possibility to leverage oslo.db's `slave_connection` parameter, which should be quite trivial to add, while providing similar behavior with just HAProxy balancing. - Big topic was adoption of ansible-core 2.19 and related challenges with role patching as well as our custom modules adoption to it. And we agreed to prioritize this work, as ansible-core 2.18 goes EOL in May 2026. - Once HAProxy role will be covered with molecule tests, we agreed to proceed with potential role refactoring, and removing obscure variables and parameters. Specifically, frontend definition is a focus, as it has some legacy, which prevents it being flexible enough for 3rd-party usage of the role. - With that we highlighted existing complexity regarding non-TLS -> TLS migrations, but uWSGI remains a blocker to move to TLS-only deployments, as HTTP 1/1 remains to be a bottleneck in terms of throughput. - We agreed to proceed to refactoring a standalone method for PKI role, and remove the necessity of storing individual certificates and private keys on the deploy host. - Attempt to add Ubuntu 26.04 support for 2026.1 Gazpacho - We touched basis on post-quantum encryption and figure out dependencies and blockers for that. With Debian 13 and Ubuntu 26.04 we will have OpenSSL 3.5, which supports already ML-KEM. However, a bunch of software, like uWSGI are still gonna be blockers to implement PQC deployment-wise. Support for things like RabbitMQ, MariaDB and etc remains unknown.

1 0

[ops][largescale-sig] Refactoring Ops-related activities - a discussion at the PTG
by Thierry Carrez 10 Nov '25

10 Nov '25

Hi everyone, A quick reminder that we'll have a session at 13:00UTC today in the PTG on how we can regroup the operators-facing activities between our various groups: the Ops meetup group, the Large Scale SIG, the Public Cloud SIG, the Scientific SIG... Join us if you can! -- Thierry Carrez (ttx)

2 2

LXB Removal and OVN migration
by Ricardo Cano 09 Nov '25

09 Nov '25

Hello openstack-discuss, With the removal of the linuxbridge mechanism driver, has anyone successfully completed an in-place migrationfrom LinuxBridge to OVN? I did come across this https://www.jimmdenton.com/migrating-lxb-to-ovn/ and that looks good as a one-shoit while biting the bullet and taking a full outage. However, I was wondering if it was possible to run lxb and ovn side-by-side and cut them over, say one network at a time. This particular deployment was stood up using openstack-ansible back in the rocky days (now running antelope) and it appears that openstack ansible's default was lxb up until Zed. Any suggestions or recommendations on the best path forward? Also, will the dynamic routing agent work with ovn?

4 3

[openstack helm] [Glance] Glance showing OSError: unable to receive chunked part when uploading image
by daniel890723＠gmail.com 08 Nov '25

08 Nov '25

Hello i'm testing using Openstack-helm to install all component but after the installation complete i can't upload the OS image through both openstack CLI or Horizon it stuck at Queueing and when i checking Glance Api log it shows 2024-11-07 07:31:19.362 7 INFO glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2024-11-07 07:31:19.400 7 ERROR glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Failed to upload image data due to internal error: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Caught error: unable to receive chunked part: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Traceback (most recent call last): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1302, in __call__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1345, in dispatch 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return method(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 415, in wrapped 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 299, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 162, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 492, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 443, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/quota/__init__.py", line 322, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 596, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 487, in _upload_to_store 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 397, in add_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 479, in store_add_to_backend_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/driver.py", line 294, in add_adapter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/capabilities.py", line 176, in op_checker 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 764, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise errors.get(e.errno, e) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 746, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi for buf in utils.chunkreadable(image_file, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 294, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = self.data.read(i) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 121, in readfn 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = fd.read(*args) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/format_inspector.py", line 956, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = self._source.read(size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1045, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi data = uwsgi.chunked_read() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Ceph Cluster Status: NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID ceph /var/lib/rook 3 82m Ready Cluster created successfully HEALTH_OK 5cf8b9bb-13e1-4c31-b47d-9e7d92c3c05d Ceph osd status: ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 0.35156 - 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 1.00 - root default -5 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 - host instance-lu-1 2 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 195 up osd.2 -3 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-2 0 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 195 up osd.0 -7 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-3 1 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 197 up osd.1 TOTAL 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 MIN/MAX VAR: 1.00/1.01 STDDEV: 0.01 now i'm able to create Empty Volume using horizon(can't create volume using default cirros image ) and i can start an Instance without volume and mount the empty volume in(Ceph also can detect when i use that volume) is there something i need to set when starting glance? because i'm following the Openstack-helm installation document to install openstack with helm

5 8

[all][tc][ptg] OpenStack Technical Committee Gazpacho PTG Summary
by Goutham Pacha Ravi 07 Nov '25

07 Nov '25

Hello Stackers, The community had a very productive "design summit" at the Project Teams Gathering last week. As you're reading the various summaries posted here, and participating in new initiatives that have rolled out since, I'd like to add a brief summary of the OpenStack Technical Committee's meetings [0] at the PTG. We recorded all of these sessions and have posted the recordings to the TC's YouTube channel [1]. Alongside this summary, I'd recommend reading the Eventlet Removal Goal updates and discussion from the session that Hervé Beraud (hberaud) hosted [2]. Remember, Etherpads are true to their name—you can lose them :D So we made a handy reference to the PTG Etherpads on the wiki [3]. Community Leaders' Forum ====================== We discussed active Community Goals [4], and took questions regarding the status from various project maintainers. As it stands, the FIPS compliance goal may no longer fit the criteria for community goals. It's been challenging due to the lack of a stable OS to test FIPS compliance in the CI. The community may need to explore CentOS Stream alternatives such as Rocky Linux 10 and Alma Linux 10. We need someone to pick up the work and replace existing test jobs. Secure RBAC has got an active Goal Champion; however, work has slowed down in several project teams. We're hoping to make another push through the Gazpacho cycle. We agreed that the current cross project liaisons information (on a wiki) is severely outdated and needs to be migrated to the openstack/governance repository, a centralized, programmatic location, to avoid duplication and ensure accuracy. We also discussed the OpenInfra AI contribution policy. Some project teams have recently seen an uptick in AI-assisted contributions, but there has been some confusion, and potential stigmatization of such contributions. We identified a need for clarity on how to apply the AI policy, specifically regarding using AI-generated code and verifying copyrights. We could use some documentation and guidelines for contributors and reviewers. Action Items: - Goutham (gouthamr) will move the FIPS goal from "selected" to "proposed" and start a separate ML thread. Project teams can remove any failing FIPS jobs when this change merges. - Tony Breeds (tonyb) will enhance the project schema in the governance repository to support adding cross-project liaisons. - (needs volunteers) The FIPS goal needs rework, especially around testing, and any objective refinements. - (needs volunteers) Clarifications and instructions pertaining to AI Contributions in the Project Team Guide. Testing and Runtimes ================= We discussed testing matrix updates for MariaDB/MySQL versions and Linux distributions. The goal is to drop older, unmaintained versions and move to modern platforms (like newer Python versions, CentOS Stream, AlmaLinux, and Rocky Linux) to ensure compatibility and support. AlmaLinux images are now available, but no projects are currently testing with them. Kolla and OpenStack-Ansible project teams are currently interested. The biggest advantage to project teams with this would be that the wide gamut of CI providers are compatible with this Red Hat-like distribution because of its support for x86_64v2 and x86_64v3 CPU architectures (as opposed to CentOS Stream or Rocky Linux). The CentOS Stream community has offered to run a third-party CI to test CentOS Stream with OpenStack, and the team noted a good meeting between maintainers in both communities at the OpenInfra Summit in Paris that Amy Marrich (spotz) facilitated. A precursor to this discussion was the concern that the latest LTS versions of MariaDB/MySQL have changed the default behavior with respect to character sets and collations, and several OpenStack services are non-compliant with these changes. We agreed that OpenStack services need to specify the character set on tables explicitly, and so creating a community goal to mandate the use of a specific character set (and to handle character set migrations) was seen as a good path forward. We briefly discussed OpenStack Special Interest Groups. We noted that we could use fresh updates to the SIGs website, including refreshing the SIG Chairs of several SIGs. There was a suggestion that, during this exercise, we could suggest merging some SIGs, such as the Scientific SIG and other operationally related SIGs, under a more general OpenStack operators umbrella. Action Items: - Dmitriy Rabotyagov (noonedeadpunk) will propose a community goal for project teams to support character set changes in newer LTS releases of MariaDB/MySQL. - tonyb will refresh the data for all the SIGs. - gouthamr will merge the governance and governance-sigs repositories for ease of management. University Partnerships and Collaborations ================================== Kendall Nelson (diablo_rojo) would like us to maintain an ongoing list of projects and mentors for OpenStack's storied university interns. This would alleviate bottlenecks and increase student engagement in OpenStack. There's now an Etherpad for this purpose [5]. If you'd like to mentor, please do sign up. We also entertained the idea of combining efforts with the First Contact SIG, as it has not been active in a while, to create a running list of mentors and participants for various onboarding events and activities throughout the community. Action Items: - Community members sign up and propose projects [5] - Revive First Contact SIG by collaborating with the University Partnership Projects. Post-Quantum Cryptography ======================= We discussed the potential breaking of traditional asymmetric cryptography by quantum computers around 2030. JP Jung (JP) joined us to detail that there are 17 cryptographic modules in OpenStack, and the goal is to understand the problem in each project, catalog the cryptographic algorithms used, and make the entire chain well-known to achieve quantum safety. A significant concern was that OpenStack has security threats today, and the energy should be directed towards securing it for current use cases as well, not just focusing on potential future threats like quantum computing. It was noted that the Python ecosystem has minimal support for post-quantum cryptography, and Python's cryptography project has not committed to a timeline for adding support, so building a foundation with cryptography or alternative libraries might be necessary before focusing on OpenStack. JP proposed a document for the community to review [6]. Much of it probably has to be less verbose and focus on specific gaps/changes. JP's willing to be a champion of the effort to secure OpenStack in a post-quantum world. He'd like project teams to audit the use of encryption algorithms, key exchange libraries/mechanisms in their deliverables. The Security SIG is a good venue to continue this discussion, and, if necessary, a sub-team or a separate pop-up team can be formed as well. Action Items: - JP will fix up the current analysis [6] to make it specific, and highlight actionable problems. OpenStack Universe a.k.a Affiliated Projects ================================== Artem Goncherov (gtema) wanted to address the issue of signaling to users that certain tools work well with OpenStack, even if they are not official OpenStack projects. The idea is to create a connection between OpenStack and these affiliated projects, giving them recognition and a voice, and potentially providing some protection from competing projects. Thierry Carrez (ttx) suggested that the OpenInfra Universe [7] is an existing platform that lists projects in a similar category, with criteria including OSI-recognized licenses and integration with Open Infra projects. We brainstormed how to evolve the current project intake form to better represent affiliated projects, with a potential meeting to include OpenInfra Marketing folks and explore options. Action Items: - ttx will set up a meeting with interested parties to improve the OpenInfra Universe, and will share updates in a future OpenStack TC meeting. Bridging the gap between community and contributing orgs ============================================= Ildiko Vancsa (ildikov), Jeremy Stanley (fungi) and Clark Boylan (clarkb) provided an update on the effort to bridge the gap between the community and contributing organizations. There are two surveys that are currently open to contributors [8] and maintainers [9]. These surveys focus on the Flamingo release cycle and will end on November 16th, 2025. (Please take them!) Once these surveys end, we're expecting them to inform us of where things are going well and where they are not, and to measure the effectiveness of changes we've slowly been making across the community, with the ultimate goal of improving the contributor experience. There is a perception that getting a feature into OpenStack requires a personal relationship with a maintainer, which can be a barrier to entry for new contributors. The complexity of OpenStack's CI and software can also be a significant technical element that makes it difficult for external contributors to get started. Collectively, we're having trouble finding new core maintainers and building knowledge in parts of our code base to sustain them. Extending trust and lowering barriers to entry can help address these issues, and projects should consider reevaluating their processes to make it easier for new contributors to get involved. It was also highlighted that #openstack and #openstack-dev IRC channels on OFTC have become less active over time. We explored the idea of revitalizing these channels as preferred venues for cross-project discussions, and having maintainers parked there to engage with folks that aren't familiar with project-specific channels or have cross-project concerns. Action Items: - Please take the contributor [8] and maintainer [9] surveys for the 2025.2 "Flamingo" release. - (ildikov/fungi) Analyze survey results when surveys close and meet with project teams and the OpenStack TC to discuss them. Project Cascade ============= Professor Corey Leong (profcorey) introduced the Cascade project, an open-source unified communications project. He asked us about the steps to make it an official OpenStack project, including potential voting and governance requirements. The project aims to integrate unified communications services, such as voice, phone, and video using open-source projects, including OpenStack components. It'd allow OpenStack users to download and install the service on their machines. Participants drew a similarity to Trove in that Cascade would provide a managed service to OpenStack users akin to Trove providing database-as-a-service. We opined that the project is still in the early stages, and the team is researching how to integrate with OpenStack components, including identifying dependencies and interactions between services. In this stage, all of the community's infrastructure: hosting on OpenDev, publishing on wiki.openstack.org, using official IRC channels on OFTC, Meetpad, Gerrit, and Zuul, are available to Project Cascade's maintainers. We tried to understand the benefits of switching to the OpenStack namespace, i.e., bringing the project under OpenStack governance and what it would provide that is not currently available. We hope to continue this discussion in a future TC meeting or on the openstack-discuss mailing list. Action Items: - tonyb is working on fixing OpenID auth issues with wiki.openstack.org and will coordinate with profcorey on problems with other maintainer infrastructure. Now that we have that out of the way, we can focus on some other important things [10]. Again, thank you very much for participating and for the great discussions over the week! Sincerely, Goutham Pacha Ravi (gouthamr) Chair, OpenStack Technical Committee [0] OpenStack TC PTG Etherpad: https://etherpad.opendev.org/p/r.5dfdc57d7bc31731ccf9d51cb80de6c5 [1] OpenStack TC Gazpacho PTG playlist: https://www.youtube.com/playlist?list=PLhwOhbQKWT7WkK5VGgipjt4XQQlgLLci9 [2] Hervé's summary of eventlet-removal: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] "Gazpacho" Oct 2025 PTG Etherpads: https://wiki.openstack.org/wiki/PTG/Oct2025PTG/Etherpads [4] OpenStack Wide Goals: https://governance.openstack.org/tc/goals/ [5] University Mentors Sign Up: https://etherpad.opendev.org/p/UPP-Projects%26Mentors [6] Post Quantum OpenStack: https://wiki.openstack.org/wiki/Post_quantum_openstack [7] OpenInfra Universe: https://openinfra.org/universe [8] Flamingo Contributor Survey: https://openinfrafoundation.formstack.com/forms/openstack_contributor_exper… [9] Flamingo Maintainer Survey: https://openinfrafoundation.formstack.com/forms/openstack_maintainer_experi… [10] https://cooking.nytimes.com/recipes/1017577-best-gazpacho

1 0

[i18n] Summary of 2026.1 Gazpacho PTG Discussions
by Seongsoo Cho 07 Nov '25

07 Nov '25

Hello all, I would like to share with you a summary of the recent discussions held during the 2026.1 Gazpacho virtual PTG regarding the i18n SIG. We had several productive sessions focused on our two main goals for the upcoming cycles: the Weblate Migration, and a forward-looking discussion on AI Translation. Special thanks to the OpenDev Infra Team for the infrastructure support, the OpenSource Contribution Academy mentees in Korea who worked on the Weblate migration, and the KNU students who brought great energy and ideas to our AI discussion. Please refer to the full details from our Etherpad: https://etherpad.opendev.org/p/oct2025-ptg-i18n 1. Weblate Migration Status & Challenges A significant portion of our PTG was dedicated to the ongoing migration from Zanata to Weblate. - Migration Status: DaGyeong Kim presented the current status. 15 dashboard projects were initially migrated, but we identified issues that require a retry. A detailed status page is tracking all projects [1]. - Tooling Development: We are actively developing and refining automation scripts to manage the migration, including language creation/deletion and handling plural forms (patches [2], [3]). This work is being tracked in a blueprint [4]. - Key Challenge - Language Definitions: We are addressing mismatches between Zanata's language codes (e.g., ko_KR) and Weblate's CLDR standards (e.g., ko), especially concerning plural form definitions. - Verification of Migration Completion: It was discussed that a clear method needs to be defined to verify whether all translated PO files in Zanata have been successfully migrated to Weblate. In subsequent discussions, it was agreed to establish specific criteria for accurate verification and to proceed with the work based on those criteria. 2. Zuul Integration & Infrastructure The second major topic was integrating our new Weblate instance with the OpenDev (Zuul) CI/CD pipeline. - Core Patches: We reviewed the main patches for openstack-zuul-jobs [5] and project-config [6] that will enable Weblate to propose translation updates. - New Zuul Job Testing Strategy: It was discussed to create a completely new job to minimize the impact and to apply it to specific projects first, gradually expanding its scope over time. 3. AI Translation PoC We held an exciting session with students from Kyungpook National University (KNU) to discuss a Proof-of-Concept (PoC) for using AI in our translation workflow. - Goals: The discussion focused on two potential tools: - An automated, CPU-based LLM tool (e.g., using Ollama) to catch new strings from merged patches and provide initial translations. - A local AI-assisted tool for translators to help with the initial translation of large .po files. - Next Steps: We are exploring different instance flavors for performance and comparing the pros/cons of self-hosting a model versus using external APIs (similar to the Firefox translation model). 4. I18n Repository Packaging We are working to package the openstack i18n repository [7] and publish an updated package to PyPI. This initiative aims to enhance productivity by independently managing the tools related to i18n. Best Regards Seongsoo Cho [1] https://wiki.openstack.org/wiki/I18nTeam/Migration-to-weblate#List_of_proje… [2] https://review.opendev.org/c/openstack/i18n/+/961371 [3] https://review.opendev.org/c/openstack/i18n/+/963758 [4] https://blueprints.launchpad.net/openstack-i18n/+spec/weblate-migration [5] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/921878 [6] https://review.opendev.org/c/openstack/project-config/+/961499 [7] https://review.opendev.org/c/openstack/i18n/+/955037

3 2

[manila] 2026.1 Gazpacho PTG summary
by Carlos Silva 07 Nov '25

07 Nov '25

Hello, Zorillas and interested stackers. Here's a summary of all the discussions, decisions, action items and plans we came up with during last week's PTG. All of the recordings are available in this playlist [10] from the OpenStack Manila Youtube channel. In case you missed something and would like to get back to the discussions, please refer to it. Flamingo Retrospective ================== We discussed what went well and what needs some attention in the upcoming cycles. - Bugsquash events and collaborative review sessions are having a positive impact on bugs being closed and features being reviewed faster. - The mid cycle helped with the reviews of the changes prior to the feature freeze. - We had several interns working on Manila UI, OpenAPI patches and fixing other known issues in Manila, providing good opportunities for community engagement. - We had enhancements on the review bandwidth but we should keep looking on adding more core reviewers to Manila and help share the load on reviews. We didn't manage to cover all topics, so the retrospective will continue in the next Manila upstream weekly meeting, November 13th. All Things CephFS: Status and Gazpacho Plans ===================================== Status updates ------------------------ - Allocated Capacity GiB fixes and thin provisioning improvements are being backported to older releases. - fs_name metadata is now also used in Manila CSI [2] - Patches to introduce CI testing for CephFS manage/unmanage operations will be included in the Gazpacho cycle. Plans for 2026.1 Gazpacho ------------------------------------ - We started testing with Ceph Tentacle release candidate images in the devstack jobs and will merge these jobs once the official Ceph Tentacle release is out. *QoS:* NFS Ganesha v7 supports QoS, i.e., throughput throttling (iops and bandwidth) Manila team intends to start the CephFS NFS driver implementation during this cycle. The implementation is expected to support the new proposed QoS types alongside driver-scoped share type extra specs. *Share encryption (BYOK):* NFS-Ganesha and Ceph communities are working on Bring-Your-Own-Key subvolume encryption. The team will work on a Proof of Concept (PoC) to extend the existing BYOK Encryption feature in Manila to support shares encryption with CephFS. *OVN extension targeting NFS-Ganesha* Discussion is ongoing with the Neutron project team for adding an extension to the OVN agent [3], which aims to improve usability and security in a cloud that relies on NFS-Ganesha to provide RWX storage volumes to end-user workloads. [NetApp] Sync snapmirror support and Async snapmirror enhancements ======================================================= NetApp is adding support for zero RPO (i.e., synchonous mirroring) with Share Replication - a feature that's been supported by this driver since the Mitaka release. Doing this will involve some more tenant-visible directives. The Manila team considered it as a good enhancement, but suggested implementing share replicas metadata as the vehicle for this change, as this will make it more extensible and reusable in the future. The NetApp team agreed with this approach and will work on implementing share replicas metadata in the Gazpacho cycle. Graduating Migration and Backup APIs ============================== Share backup APIs -------------------------- The Share Backup APIs are mostly feature complete. We're missing a way to force backup deletion and the ability to set backup quota via the CLI and UI. Some improvements are planned for the Share Backup driver abstraction as well. We are also evaluating the possibility of adding testing with CERN's CBACK utility and Backup driver in the CI, and Zac is working on further enhancements for targeted restores. Share migration APIs status ------------------------------------- The share migration APIs have been stable for a while and well tested. We believe that this API is ready to be graduated and we need a contributor to help drive this to completion. Share Encryption follow up ==================== The Manila team discussed the known issues and gaps noted while reviewing and merging this feature in the flamingo cycle: - Inability to unmanage/manage share servers with encrypted shares: the NetApp team will investigate how to implement the changes to the manage share servers workflow. - We agreed that this should also follow steps similar to the creation workflow, as, for example, checking if the barbican key exists, if the user can manipulate it, and if it matches the one from the share server. - Inability to migrate share servers and setup share replication: the NetApp team will look into the required next steps. NetApp - NAE (NetApp Aggregate Encryption) Support ========================================== NetApp is planning to add support for encrypted pools (aggregates) to Manila when DHSS=True is in use [4]. It will allow customers to encrypt the shares (volumes) data by assigning the encryption key to aggregate level. The Manila team is okay with this proposal and the NetApp team will start this implementation in the Gazpacho release cycle. Adding new/failure notification ======================= We currently have notifications for share operations (create, shrink, delete). eunkyung, a contributor from Samsung would like to add notifications for other operations in Manila (creating snapshots, reverting to snapshots and others). The team agreed that this is a great addition, as we started with notifications for shares but didn't have the cycles for adding notifications to other resources. This change will be proposed to Manila and the Manila team will share feedback. Add mount_point_name option to managing share ====================================== It is currently possible to define a custom mount point name to a share export location, but while managing a share, it is not possible. We discussed the possibility of extending this feature to the manage workflow and agreed that this is will be a great improvement for the operators. This feature will be proposed during the Gazpacho cycle and the Manila team will review. QoS enhancements =============== Kiran shared a proposal for introducing QoS types in Manila, with the possibility of having multiple QoS types being linked to a share type. The QoS types will be added to the share servers and shares created. The team agrees that this is a nice addition, and we asked more details in the specification [5] seeking clarifications on spec conflicts and to elaborate on the need to tie the QoS types to the share type itself, instead of using an approach to tie them directly to shares or share servers. Eventlet Removal ============= The manila team is actively working on removing eventlet. We used this topic to talk about the progress from the team, share our plans, roadmap and discuss an issue shared by Eric from the Cinder team, where sqlalchemy objects shared by multiple threads were affected when dropping eventlet from the cinder-volume service. damani joined us for the discussion and has started on changes that are going to address this behavior [6][7]. The Manila team intends to support running all manila components without eventlet by the end of the Gazpacho release. Dropping the v1 API =============== The Manila v1 API was deprecated ~10 years ago and we intend to remove it during the Gazpacho Cycle. Removing it will clean up our code and make enhancements such as the JSON Schema Validation work easier. This work will help us with the OpenAPI schema and documenatation enhancements that we've been slowly closing the gap on for the past few releases. AI: carloss will send an email to the mailing list announcing the removal. JSON Schema Validation =================== We shared the current status of the JSON Schema validation changes in Manila and also talked about the lack of reviews in the open changes. We decided to split changes up into smaller chunks, making it more friendly to new contributors, and to reviewers. AI: carloss will organize a Review Jam to help making progress, as well as unify the tracking of the current issues being worked on in a Taiga board [8]. Manila client removal + merging manilaclient's OSC functionality into OSC ======================================================== The Manila CLI utility was deprecated several release cycles ago and we intend to remove it in the Gazpacho cycle. We also discussed moving Manila's OSC functionality from python-manilaclient into openstackclient itself. Doing this will reduce the burden to discover and import command modules at runtime, significantly improving performance of OSC. We discussed the work that would be needed and how it would affect the release process. NetApp REST/ZAPI situation ====================== Retirement of NetApp's ONTAPI is currently on hold [9]. Many OpenStack users are still heavily relying on ZAPI because of how the NetApp drivers in Cinder and Manila integrate with the product. All new ONTAP features will be added only to REST, with no fallback approach to ZAPI. So, the drivers in OpenStack have started seeing implementation changes over several releases to support NetApp's REST API where available. The NetApp team is also putting efforts into identifying the gaps between REST and ZAPI in Manila. As for CI Testing: Stabilizing CI runs with REST is a priority for the NetApp team, with an engineer actively working on the necessary fixes. Improvements for managing shares/snapshots =================================== The proposal is to update the snapshot's created_at field to reflect the creating time on the storage backend during the manage operation, rather than the time recorded by Manila. We agreed with the proposal but also think this should be applied for the shares. A blueprint will be registered and inyonghong will work on the fix. Dell's PowerScale driver roadmap ========================== We heard requests for a couple of features in the Dell PowerScale drivers: - manage/unmanage for shares and snapshots - revert to snashot - custom mount point names - QoS. We noted that the revert to snapshot feature is already being worked on by the Dell team and the Manila team will review the changes and target them for the gazpacho cycle. [1] https://etherpad.opendev.org/p/gazpacho-ptg-manila [2] https://github.com/kubernetes/cloud-provider-openstack/pull/2994 [3] https://review.opendev.org/c/openstack/neutron-specs/+/936063/3/specs/2025.… [4] https://etherpad.opendev.org/p/nteapp_nae_support [5] https://review.opendev.org/c/openstack/manila-specs/+/962706 [6] https://review.opendev.org/c/openstack/oslo.service/+/963742 [7] https://review.opendev.org/c/openstack/oslo.service/+/965208 [8] https://tree.taiga.io/project/gouthampacha-manila-jsonschema-openapi/kanban [9] https://kb.netapp.com/on-prem/ontap/DM/REST-API/REST_API_KBs/Deferral_of_ON… [10] https://www.youtube.com/watch?v=3O3ByYU6gHc&list=PLnpzT0InFrqAf4kRsXDoVpv0V… Lots of positives to take from this PTG and definitely a productive cycle ahead. Thank you for your participation! Regards, carloss

1 0

[release] Release countdown for week R-20, Nov 10 - 14
by Elõd Illés 07 Nov '25

07 Nov '25

Development Focus ----------------- The Gazpacho-1 milestone is next week, on November 13th, 2025! Project team plans for the 2026.1 Gazpacho cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the 2025.2 Flamingo release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Gazpacho-1 milestone: November 13th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[Action required] Glanceclient freeze in I cycle
by Cyril Roelandt 07 Nov '25

07 Nov '25

Hello, The Glance team is planning on freezing development on python-glancelient. Starting in the I cycle, the client will go into maintenance mode, and new features will no longer be implemented. Users are encouraged to use the OpenStack client instead and report bugs or missing features to the SDK or OSC projects. The following projects currently use glanceclient as a library: - ceilometer[1] - cinder - cyborg - freezer - heat - heat-translator - horizon - magnum - manila[2] - mistral-extra - nova - octavia - os-client-config - rally-openstack - skyline-apiserver[3] - sunbeam-charms - trove - venus[4] - vitrage-tempest-plugin - zun The Glance team has proposed some migration patches already to some of the affected projects. We would appreciate your team's quick attention to reviewing these patches during this cycle. Additionally, we will be happy to help review migration patches proposed by your team. Use the topic 'remove-glanceclient' so we can easily find them. We're starting the migration process now in Gazpacho so that we can discover and address any feature gaps well in advance of the glanceclient going dark in the I release. On behalf of the Glance team, Cyril Roelandt [1] https://review.opendev.org/c/openstack/ceilometer/+/963632 [2] https://review.opendev.org/c/openstack/manila/+/935835 [3] https://review.opendev.org/c/openstack/skyline-apiserver/+/963862 [4] https://review.opendev.org/c/openstack/venus/+/931291

1 0

[tacker][ptg] 2026.1 Gazpacho PTG summary
by Yasufumi Ogawa 07 Nov '25

07 Nov '25

Hi all, I'd like to share a brief summary of Tacker vPTG. Please refer to our etherpad [1] for whole the duscussion. [1] https://etherpad.opendev.org/p/oct2025-ptg-tacker ## Enhancing Tacker Testing Coverage in the OpenStack Helm Check Pipeline - It's a recap from the previous cycle. To expand the test coverage, improve Tacker testing within the OpenStack Helm (OSH) pipeline by adding more test cases. - Use the OpenStack CLI for Tacker testing, ensuring that no modifications to the OSH test code will be needed even if Tacker's functional tests change. ## Tosca-parser 2.13.0 Validation Failures – Tacker Handling Strategy for Specification Gaps in ETSI SOL001 v2.6.1 - Address the validation failures in tosca-parser happened after it's updated to v2.13.0. - Some VNFDs in tacker's repo are still old and invalid for the stricter validations, but required to be not changed for keeping compatibility with ETSI std version v2.6.1. - We introduced temporary fix just for passing the tests as a remedy, but haven't conclude our policy how we keep the compatibility. As the result, current tacker impl isn't fully compatible with ETSI std. - Continue the discussion for the policy while adding a note for describing the current status of the issue on docs. ## Approach to Prevent Broken Reference URLs in Tacker Documentation - For better maintenance, introduce a periodic job for detecting invalid links. ## Proposal for New Compliance Testcase Implementation for ETSI TST010 Release 3 - Implement new ETSI TST010 Release 3 (v3.3.1) testcases to continue alignment with the ETSI std and strengthen its compliance verification capabilities for VNFM APIs. ## Enabling VNF Support in Prometheus Plugin for Fault Management - Extend Tacker's Prometheus Plugin to enable Fault Management support for VNFs which suppports only CNFs. ## Fix VNF-Package Multi-tenancy issues - Enable multi-tenancy support in VNF Package management by changing the uniqueness scope of vnfd_id from global to per-project. - Due to the current NFV does not support VNF level multi-tenant and it might be a gap between ETSI std, continue to discuss how we fill the gap, for example, making a feedback for multi-tenancy usecase or so. ## Confirm support versions for k8s/Helm/Prometheus on Tacker Gazpacho - The current support versions of k8s/Helm/Prometheus aren't the latest since we've had a failure of updating patch and cannot be fixed yet. - Fix the issue and update to the latest. ## Eventlet removal (Community goal) - Tacker depends on eventlet and need to be modified for the removal. - NEC will discuss if we can proceed with this work. ## Bug triage - Revise Bug maintenance on launchpad for closing too old bugs labeled as critical but can be discarded anymore or so. - Go through the bug list and give comments about their related bugs Thanks, Yasufumi

1 0

[qa] Tempest gate blocked and dropping python 3.9
by Ghanshyam Maan 06 Nov '25

06 Nov '25

Hi All, Requirement repo has dropped the Python 3.9 constraints[1], and due to that, the Tempest gate is blocked because the Python 3.9 unit test job is failing. We discussed this type of issue in the past[2], that if the requirement repo drops older Python version constraints, then Tempest can drop the support of that Pythion version. Tempest master can still be used to test the Python 3.9 env; for that, you need to install tempest in a Python 3.10 (or higher) env. I have proposed the change to drop py3.9[3], and Yatin's change will unblock the stable branch testing[4]. Hold your recheck until those fixes are merged. [1] https://review.opendev.org/c/openstack/requirements/+/957587 [2] https://lists.openstack.org/pipermail/openstack-discuss/2022-May/028711.html [3] https://review.opendev.org/c/openstack/tempest/+/966101 [4] https://review.opendev.org/c/openstack/tempest/+/965903 -gmaan

1 3

[watcher] Unmaintained branch cleanup
by Joan Gilabert 06 Nov '25

06 Nov '25

Hi everyone, Watcher currently has two unmaintained branches[1], unmaintained/2024.1 and unmaintained/2023.1. The latter has not had any patch in 2 years [2] so we plan to move it to eol. We will discuss it in the next Watcher IRC meeting, but I'm writing this message early to give everyone a chance to raise any objection. Please respond to this message if you have any objection, if there are none, I will propose a patch to move the branch next Thursday, after the Watcher IRC meeting and share the link here. Regards, Joan [1] https://opendev.org/openstack/watcher/branches [2] https://opendev.org/openstack/watcher/commits/branch/unmaintained/2023.1

2 2

[kolla-ansible] nova ceph backend
by Jonathan Proulx 06 Nov '25

06 Nov '25

Hi All, looking at https://docs.openstack.org/kolla-ansible/2025.1/reference/storage/external-… To use ceph with my particular setup it seems I need to set this in globals.yml: nova_backend_ceph: "yes" ceph_nova_user: "nova" ceph_nova_pool_name: "ov-vms" And provide the keyring file in config/nova/ceph.client.nova.keyring I'm not configuring cells explicitly but when I run `kolla-ansible reconfigure --tags nova` I get: ASK [nova-cell : Check cinder keyring file] ************************************************************************** fatal: [kvmgen6-0.csail.mit.edu -> localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable.. ['{{ node_custom_config }}/nova/{{ inventory_hostname }}/{{ keyring }}', '{{ node_custom_config }}/nova/{{ keyring }}']: {{ nova_cell_ceph_backend['cluster'] }}.client.{{ nova_cell_ceph_backend['volumes']['user'] }}.keyring: 'dict object' has no attribute 'volumes'\n\nThe error appears to be in '/opt/kolla/venv/share/kolla-ansible/ansible/roles/nova-cell/tasks/external_ceph.yml': line 17, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Check cinder keyring file\n ^ here\n"} Digging through the code in roles/nova-cell/tasks/external_ceph.yml I kind of make it go by adding: nova_cell_ceph_backend: cluster: "ceph" vms: user: "{{ ceph_nova_user }}" pool: "{{ ceph_nova_pool_name }}" volumes: user: "{{ ceph_nova_user }}" pool: "{{ ceph_nova_pool_name }}" but I can find no reference in the docs to this and don't understand what in needs "volumes" for (And suspect it should be using some cinder stuff for that?) What have I done here? The nova backend "works" but I worry about how I got here since nova+cinder is very common and I shoudl not have needed to leave the documented path so I worry there's a deeper error in my config that caused this. Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 2

[nova] NVLink passthrough
by Pavlo Shchelokovskyy 05 Nov '25

05 Nov '25

Hi all, This is a continuing thread from 3 years ago here: https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029273.ht… We've recently faced the same issue re Nvidia NVLink / NVSwitch, and I wanted to share how we are solving it. Given: - server with 8x Nvidia H200 pGPUs aimed to be used as PCI passthrough - separate pGPUs can be connected with NVLink but not any with any - there are 4 specific combinations to use when pairing 2 gpus - gpu1+gpu3, gpu2+gpu4, gpu5+gpu7, gpu6+gpu8 - and there are only 2 possible combinations of pairing 4 gpus - gpu{1..4} and gpu{5..8} The requirement is to have a single flavor that would ask for 2 GPUs, and the scheduling would pick only appropriate pair where NVLink between GPUs is possible, and compute will enable/disable NVLink for those GPUs as appropriate (same for 4 GPUs flavor). The compute part is solved by a libvirt hook provided by Nvidia here https://github.com/NVIDIA/libvirt-hooks/. Given the correct devices are chosen by Nova to be passed into the VM, the hook will enable NVLink between them. However, that scheduling part is currently rather impossible with Nova as-is. The best one can do is assign separate trait to appropriate pairs and quartets of GPUs, and then have 4 flavors for 2-GPU configuration and 2 flavors for the 4-GPU one. This if course is very inefficient and brittle, and can not work in a self-service cloud. What we are trying to do is the following: - add a new flavor extra spec `placement:same_subtree`. The value will be passed directly to placement's allocation candidates API. - in order for this to be usable in a flavor, we need predictable resource group names generated for PCI devices. Right now they are auto-generated from request-id, which won't work. - hence we extended `pci_passthrough:alias` spec to have an optional `:group_prefix` part. Then, what we do is reshape the PCI resource provider tree a bit. We introduce two extra layers of providers, let's call them `group4` and `group2`, each group has a specific trait, for example `CUSTOM_PCI_GROUP_OF_2` and `CUSTOM_PCI_GROUP_OF_4`. Two `group4` providers have compute nodes as a parent, and are parent to two `group2` providers each. Then we re-parent PCI resource providers to `group2` providers, so that each `group2` and `group4` tree corresponds to a set of GPUs that can be connected via NVLink. Luckily enough, resource tracker of nova-compute does not care about the parent provider, as long as the name and ID of PCI resource providers are not changed, so the reshape has no effect on the resource tracker. We also need to use all this with Aggregate Extra Spec filter active, so we've duplicated the `group_policy` flavor extra spec to `placement:group_policy` one. And of course, for all of this to work, one has to enable "PCI in placement" feature too https://docs.openstack.org/nova/2025.2/admin/pci-passthrough.html#pci-track… As a result, assuming the PCI alias for the GPUs is `h200` and its resource class is `PGPU`, we can create the following flavor extra spec: pci_passthrough:alias=h200:2:_nvlink2 trait_groupof2:CUSTOM_PCI_GROUP_OF_2=required placement:group_policy=none placement:same_subtree=_nvlink2-0,_nvlink2-1,_groupof2 that will result in the following placement query: GET /allocation_candidates ?resources_nvlink2-0=PGPU:1 &resources_nvlink2-1=PGPU:1 &required_groupof2=CUSTOM_PCI_GROUP_OF_2 &group_policy=none &same_subtree=_nvlink2-0,_nvlink2-1,_groupof2 That will select only a pair of GPUs that are children of a single provider with `CUSTOM_PCI_GROUP_OF_2` trait - which is exactly what we need! You can find this work proposed as a patch at https://review.opendev.org/966205. This is definitely just a beginning of discussion, and most certainly would require a spec, so I am eager to hear your thoughts and comments :-) Cheers, pas-ha -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

2 1

[horizon][PTG] 2026.1 Gazpacho PTG summary
by Tatiana Ovchinnikova 05 Nov '25

05 Nov '25

Hello everyone, A huge thank you to everyone who joined the OpenStack Horizon team for the Gazpacho PTG, who organized sessions, presented topics, and actively contributed to the discussions! Thank you for making the PTG a success! The full list of sessions and topics can be found on our Etherpad [1] Here is the summary of the topics: # Flamingo Retrospective A review of the previous Flamingo cycle, highlighting positive developments like switching to SDK for certain services, improving TOTP setup, and improving region/domain selection. # Gazpacho Cycle Planning Planning for the current Gazpacho cycle, establishing AngularJS removal as the top priority. Other key goals include investigating the removal of old integration tests and planning for Django 5.2 support. # Open Discussion A session for discussing various in-progress code reviews. Topics included a discussion on a feature to add changing instance password support. # Django 5.2 Support Discussion on the plan to adopt Django 5.2, the latest LTS release. # Tests Review of current test stability and plans for test code cleanup. The team noted that both horizon-integration-pytest and horizon-ui-pytest are currently stable and plans to remove old integration tests from the repository are moving forward. We also discussed progress on implementing Manila UI integration tests as a template for other plugin teams. # Towards New OpenStack contributors: An OpenInfra User Group Kenya Story A presentation by Agnes Nduta to share the experiences and strategies of the OpenInfra User Group Kenya in successfully onboarding new contributors into the OpenStack ecosystem. # Contributor/Maintainer Surveys and Metrics Analysis A review of current project health using metrics and analysis from contributor and maintainer surveys. # How to create a Cursor MCP for analyzing Horizon code A walk-through demonstrating the steps required to set up a Cursor Maintainer Candidate Program (MCP) for analyzing Horizon code. # Multi-Realm Support and Multi-Region Support discussion A dedicated cross project session to discuss the implementation and implications of providing Multi-Realm and Multi-Region support within the Horizon dashboard. More details can be found on the separate Etherpad [2]. [1] https://etherpad.opendev.org/p/horizon-gazpacho-ptg [2] https://etherpad.opendev.org/p/multi-realm With kind regards, Tatiana

1 0

Nova error for fetch or server create after upgrade
by Ahmad Milad Pour 05 Nov '25

05 Nov '25

Hello there, I did upgrade the packages and repo, and something were upgraded: BEFORE: root@gregion83:~# apt-cache policy nova-api | head -n 10 nova-api: Installed: 3:29.2.0-0ubuntu1.1 AFTER: root@gregion83:~# apt-cache policy nova-api | head nova-api: Installed: 3:31.0.0-0ubuntu1.2~cloud0 I also did add "DEBUG=True" under "default" section of /etc/nova/nova.conf in my region and tried to create server, but I cannot find any important logs or details to see what's wrong: ==> /var/log/nova/nova-api.log <== 2025-11-05 14:42:44.524 2960 INFO nova.osapi_compute.wsgi.server [-] 185.137.25.83 "GET /v2.1 HTTP/1.1" status: 200 len: 790 time: 0.0164449 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi [None req-892920aa-c4be-4aea-abab-aa8e9fe8c7e0 64c74c80ec9a4a31ae27b82af846b36a 906db1c682bc4e3db 822c2e6dbc9cb6a - - default default] Unexpected exception in API method: neutronclient.common.exceptions.InternalServerError: Request Failed: internal serve r error while processing your request. Neutron server returns request_ids: ['req-80f3ccda-11ee-4417-a27c-2437540e6ee0'] 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi exception_handler_v20(status_code, error_body) 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/neutronclient/v2_0/client.py", line 90, in exception_handler_v20 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi raise client_exc(message=error_message, 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi neutronclient.common.exceptions.InternalServerError: Request Failed: internal server error while processing your request. 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi Neutron server returns request_ids: ['req-80f3ccda-11ee-4417-a27c-2437540e6ee0'] 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi 2025-11-05 14:42:45.628 2960 INFO nova.api.openstack.wsgi [None req-892920aa-c4be-4aea-abab-aa8e9fe8c7e0 64c74c80ec9a4a31ae27b82af846b36a 906db1c682bc4e3db822c2e6dbc9cb6a - - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. <class 'neutronclient.common.exceptions.InternalServerError'> 2025-11-05 14:42:45.632 2960 INFO nova.osapi_compute.wsgi.server [None req-892920aa-c4be-4aea-abab-aa8e9fe8c7e0 64c74c80ec9a4a31ae27b82af846b36a 906db1c682bc4e3db822c2e6dbc9cb6a - - default default] 185.137.25.83 "GET /v2.1/servers/c18f669d-1338-42dd-947f-c40217238450 HTTP/1.1" status: 500 len: 660 time: 1.1018338 My last openstack version was 6.6.0, and I did upgrade after another email I sent "How to install Flamingo openstack in Ubuntu 24". Before upgrade, everything was working fine, but now I have issue. Would you please help me for this? Regards, Ahmad

2 3

How to install Flamingo openstack in Ubuntu 24
by Ahmad Milad Pour 05 Nov '25

05 Nov '25

Hello there, I use Ubuntu 24 and I did try to install openstack, but it seems it's not the latest one. root@gregion83:~# cat /etc/os-release PRETTY_NAME="Ubuntu 24.04.3 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.3 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL=" https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo root@gregion83:~# openstack --version openstack 6.6.0 root@gregion83:~# apt-cache policy nova-api | head -n 10 nova-api: Installed: 3:29.2.0-0ubuntu1.1 Candidate: 3:29.2.0-0ubuntu1.2 Version table: 3:29.2.0-0ubuntu1.2 500 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages *** 3:29.2.0-0ubuntu1.1 100 100 /var/lib/dpkg/status 3:29.0.1-0ubuntu1.4 500 500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages root@gregion83:~# apt-cache policy openstack-dashboard | head -n 10 openstack-dashboard: Installed: 4:24.0.1-0ubuntu0.24.04.1 Candidate: 4:24.0.1-0ubuntu0.24.04.1 Version table: *** 4:24.0.1-0ubuntu0.24.04.1 500 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages 100 /var/lib/dpkg/status 4:24.0.0-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages root@gregion83:~# curl -s -H "X-Auth-Token: $(openstack token issue -c id -f value)" http://$HOSTNAME:8774 | jq { "versions": [ { "id": "v2.0", "status": "SUPPORTED", "version": "", "min_version": "", "updated": "2011-01-21T11:33:21Z", "links": [ { "rel": "self", "href": "http://gregion83.domain.com:8774/v2/" } ] }, { "id": "v2.1", "status": "CURRENT", "version": "2.96", "min_version": "2.1", "updated": "2013-07-23T11:33:21Z", "links": [ { "rel": "self", "href": "http://gregion83.com:8774/v2.1/" } ] } ] } That's the information I thought is good for the help. And that's the error I have: root@gregion83:~# openstack server rebuild --image 608349cf-8743-4339-8e2c-e707f89be64f --no-user-data c18f669d-1338-42dd-947f-c40217238450 --os-compute-api-version 2.54 or greater is required to support the --no-user-data option root@gregion83:~# openstack server rebuild --image 608349cf-8743-4339-8e2c-e707f89be64f --user-data /dev/null c18f669d-1338-42dd-947f-c40217238450 --os-compute-api-version 2.54 or greater is required to support the --user-data option I see this link from which I can install: https://docs.openstack.org/horizon/2025.2/install/install-ubuntu.html How to resolve this issue? Regards, Ahmad

3 4

[kolla-ansible] Upgrade from 2024.1 to 2024.1 neutron-l3-agent unhealthy
by hamid.lotfi＠gmail.com 04 Nov '25

04 Nov '25

Hi everyone, I’m hitting a weird issue after a kolla-ansible upgrade and would appreciate any pointers. Environment kolla-ansible 18.8.1 rabbitmq 4.1.3 (deployed by Kolla) upgrade path: 2024.1 → 2025.1 What happened Ran kolla-ansible -i … upgrade from 2024.1 to 2025.1. The upgrade finished without obvious errors in kolla logs. Right after the upgrade every neutron-l3-agent container on all control/compute nodes is marked unhealthy (no ERROR/FATAL lines in the container logs). All tenant instances lose external connectivity. Simply docker restart neutron_l3_agent on each node is enough: containers become healthy and external access is restored instantly. No other OpenStack service shows the same behaviour. Any idea why the agents start in “unhealthy” state until manually restarted? Happy to collect more data if you tell me what to look for.

1 0

[ops][largescale-sig][scientific-sig] Ops Radio Hour on October 31, 2025 at the PTG
by Ildiko Vancsa 04 Nov '25

04 Nov '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __October 31st, 2025 at 1300UTC,__ which is during the PTG! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. The main topic of the next gathering will be to discuss how to refactor Ops-related activities. See Thierry's email for more details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on October 31st! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[horizon] Cancelling weekly meeting tomorrow
by Tatiana Ovchinnikova 04 Nov '25

04 Nov '25

Hello team, I don't have anything to share after the PTG, so I'm cancelling the IRC meeting tomorrow, November 5th. Let's save some time for the reviews and see you next week! With kind regards, Tatiana

1 0

[ironic][all] Making core teams more accessible
by Jay Faulkner 04 Nov '25

04 Nov '25

I'm going to preface this with a comment that I'm not completely sold on this idea yet, but I think it's worth a larger discussion and might be a seed to help with discussion. I've tagged Ironic as this proposal is for Ironic specifically, but I'm very, very interested in the larger community opinion for this kind of approach so I also tagged all. One of the toughest parts about walking the path to becoming core is how fuzzy the targets are. With Ironic recently having added a two-tier review system, with reviewers and approvers separate, we have an opportunity to allow a much, much bigger tent for the ironic-reviewers group without risking code getting merged without approval by one of our folks with more experience and context in OpenStack and Ironic as a whole. So here's the suggestion -- we come up with a static criteria and period with a clear bar to "if you do this, you are an ironic-reviewer". For instance, we could say (I'm not sure about these numbers): if you do an average of Y (5?) reviews/week and have merged a major Ironic feature or multiple bugfix patches, you would automatically be a reviewer. Obviously, we'd have to keep safeguards to prevent abuse; in our community in the past we had a rule that changes required review from two separate corporate entities -- in this case, I'd suggest a waiting period to prevent quick-merging by someone with a single perspective. Exceptions would be, as in the current system, for emergency CI fixes and documentation improvements. To be clear: the safeguards shouldn't be seen as a lack of trust, but maybe instead as an acknowledgement that structural controls hold value even if there's no reason to assume mistrust. Full proposal: * ironic-approvers (+2 and Workflow +1) continues to operate as usual, with admission being based on technical merit, trust, and review frequency. * ironic-reviewers (+2 only) becomes a data-driven group, where reviewers are added/removed based on individual performance metrics TBD (likely reviews/commits/bugs fixed). -- I'll note that today, there's not really any set of reasonable metrics that would add additional reviewers to this group. * Code changes would either need a review from two separate company-representatives, or to have sat for a short waiting period to ensure other folks had a chance to look at it. * Urgent CI fixes, trivial changes, and documentation updates would still only need one review to land. What do folks think? Would this be a good carrot for existing non-cores to up their review and upstream contribution commitments? - Jay Faulkner G-Research OSS

6 6

[nova] Patch for Calico with libvirt >= 9.5.0
by Nell Jerram 04 Nov '25

04 Nov '25

I apologise if this is the wrong place to ask, but is there something I can do to encourage review and approval for https://review.opendev.org/c/openstack/nova/+/960284 ? Many thanks - Nell

2 2

[manila] Cancelling Nov 6th weekly meeting
by Carlos Silva 04 Nov '25

04 Nov '25

Hello Zorillas and interested stackers, As discussed in the previous upstream weekly meeting, we're cancelling this week's meeting, so we have some extra time to go through PTG action items before we regroup. The next meeting will be on Nov 13th. Thank you, carloss

1 0

Kolla-Ansible deployment results in broken dashboard
by Ricardo Matheus 04 Nov '25

04 Nov '25

Hi all I just deployed a multinode OpenStack using Kolla-Ansible, but it seems that the Horizon image (ubuntu / master) is somewhat broken. Horizon runs and the dashboard is accessible, but every file in the "static" part of the web server is not available (no logo images, no css, nothing... just plain unformatted html). Is this a known bug? (btw, there was a guy asking about the same problem in irc a few days ago, it is in the logs for 2025-10-23 (Thursday) <https://meetings.opendev.org/irclogs/%23openstack/%23openstack.2025-10-23.l…> ) Cheers! RDM

2 2

[ptg] #eventlet-removal 2026.1 Gazpacho PTG summary
by Herve Beraud 04 Nov '25

04 Nov '25

Hi everyone, Following our last week PTG meeting, I’d like to share a brief summary of the key outcomes, achievements, and next steps we agreed upon for the Eventlet removal initiative. ## Flamingo Retrospective We have crossed an important milestone: over 50% of impacted projects have shown significant migration progress. 19 deliverables are fully migrated, while 32 others are currently undergoing migration work. Here are the main accomplishments delivered during Flamingo: - Eventlet now includes support for Python 3.14, ensuring compatibility with upcoming Python releases; - Oslo.service introduced a new threading backend to provide a fully threading-based execution model; - Ironic, Heat, Barbican, Mistral, and several other projects are now fully migrated; - the Neutron migration is just one step away from completion; - Nova-api, nova-metadata-api, nova-conductor nova-scheduler can now run in threading mode. ## Gazpacho Call to Actions The following actions are expected to structure our efforts for the Gazpacho development cycle: - we must enhance oslo.service to prevent fork-inherited lock deadlocks by defaulting to the spawn multiprocessing start method, which will address known Manila and Cinder bugs; WIP https://review.opendev.org/c/openstack/oslo.service/+/963742 - we are preparing to merge the new opt-in H905 hacking rule to ensure consistent Eventlet usage detection across all OpenStack projects (see: https://review.opendev.org/c/openstack/hacking/+/959699) - we should clean up the bug tracker of migrated projects to reflect the current status of the eventlet removal efforts. Many of those projects surely have historical eventlet bugs that could be closed; - we need to maintain momentum on ongoing migrations and accelerate progress on the most delayed projects; - we should prioritize the “low-hanging-fruit” migrations, such as Cyborg and Magnum. ## Project Needing Attention Several projects have not shown any notable update during this cycle and require focus in the next series. These projects still contain Eventlet occurrences that must be addressed urgently: Blazar, Venus, Tacker, Masakari, and Zun. The TC has marked Venus and Vitrage as inactive, and these teams may be retired in 2026.2 if activity does not resume. ## Open Discussion Nova plans to focus on nova-compute, nova-novncproxy, testing improvements, and Rally-based benchmarking to fine-tune thread pool defaults, making Gazpacho the likely cycle where Nova fully switches from Eventlet to threading. Dan Smith presented a strategy idea for Glance that we could name the “Optional Eventlet Shim Strategy.” The goal of this approach is to make the use of Eventlet fully optional, allowing Glance to run without this dependency by default. To achieve this, all Eventlet-related code would be isolated outside of Glance’s core and moved into a separate module acting as a bridge. The core of Glance would remain unique and free of any references to Eventlet. If users still wish to rely on Eventlet, they would be able to install an additional module that provides the required implementation. Without this module, Glance would naturally run using the native threads concurrency mode. This approach offers a smooth transition path while preserving the ability to revert if needed, ultimately moving Glance toward a fully Eventlet-free architecture. Thank you to everyone who contributed during the PTG discussions and for the continuous efforts across teams. Let’s keep the momentum going as we enter the Gazpacho cycle and move closer to a fully Eventlet-free OpenStack. As always, you’re welcome to join us on IRC at #openstack-eventlet-removal, and you can find guidance, resources, and updates at https://removal.eventlet.org/ Thanks for your attention. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[watcher] 2026.1 Gazpacho PTG summary
by Douglas Viroel 04 Nov '25

04 Nov '25

Hi all, Last week's PTG had a lot of great discussions, covering many different aspects of the Watcher project. If you want to get mode details about a topic, you can find the PTG etherpad with all notes here https://etherpad.opendev.org/p/watcher-2026.1-ptg Here is a summary of the discussions that we had: Future of datasources backends and untested integrations *Discussion*: The discussion revolved around the removal timeline for Monasca, the status of Gnocchi, and the deprecation of Prometheus datasource in favor of Aetos. There was also a proposal to deprecate MAAS support due to lack of testing and documentation, and to re-evaluate experimental integrations in 2026.2. *Agreed*: - AI(jgilaber): Monasca datasource will be removed this cycle. - More research is needed on current Gnocchi usage, and there will be no change in its support this cycle. Suggestion: include a question about gnocchi in the next openstack user survey. - AI(jgilaber): Prometheus will be deprecated in 2026.1 in favor of Aetos. Suggestion: include documentation on how to upgrade between datasources. - AI(dviroel): MAAS will be marked as deprecated this cycle, since it has Eventlet dependent code that is planned to be removed in a near future. We will send another email to the ML to call for maintainers. - AI(sean-k-mooney): Update Watcher documentation about service integrations that are now deprecated. Openstack SDK *Discussion*: It was focused on integrating Watcher with the OpenStack SDK to deprecate and remove the python-bindings in other places. The goal for watcher is to replace the current usage of the project's client with the SDK instead (if there is support for it). The goal for python-watcherclient is to only provide the *openstackclient* plugin and replace python binding by adopting the usage of the SDK (when available). And for the watcher-dashboard is to use the SDK exclusively for API interactions (also when available). *Agreed*: - Start with watcher integrations. The goal is to move one service client (e.g.: Nova) to the SDK this cycle. - Do not freeze python bindings until SDK support is in place. - A single spec can address the overall plan. Code modernization, dependencies and dead code removal *Discussion*: The discussion covered code modernization using pyupdate and potentially ruff for cleanup. It also addressed the removal of dead code, such as API routes that always raised exceptions and commented-out code in production files. The removal of various client dependencies (Neutron, Glance, Monasca) was also proposed. *Agreed*: - Apply the same pre-commit and ruff linting checks to the tempest plugin and watcher client. - Defer decisions on more typing until necessary, possibly starting with interfaces. - Explore dropping the number of dependencies, such as multiple timezone libraries. Applier's Workflow Execution and Its Interface/Contract *Discussion*: The workflow for the Applier was identified as poorly documented, leading to questions during reviews of new actions. The need for a default Action interface was discussed. *Agreed*: - The assessment of a default Action interface will be based on the chosen path for rollback and aborting topics. - AI(dviroel): Current interface needs to be documented regardless. Applier: Aborting running tasks *Discussion*: The current implementation of the Applier spawning a new green thread for each action, and killing threads for actions that support abort(), was discussed. *Agreed*: - Stop spawning/killing threads on every action. This code can be refactored right after we merge the eventlet changes in the applier (so we don't mix the proposals). - Improve the execute() method in actions to check resource status and abort the process/looping when an action is cancelled/aborted. Applier: Rollback of Action Plans *Discussion*: The current lack of a working rollback mechanism and the fact that the revert() method from Actions is not being tested or called were highlighted. The future of the rollback option was debated. New rollback mechanisms, such as a user-triggered "rollback" action for failed action plans, were also considered. *Agreed*: - Auto-revert does not work and should be removed in the future. - AI(dviroel): Current behavior should be treated as a bug, and the documentation and associated configuration options should be updated accordingly. - A new spec should be proposed for a new action plan to revert workflow. CI Testing and Coverage *Discussion*: The naming and refactoring of watcher CI jobs were discussed. The need for every voting job in check to also run in the gate was emphasized, as well as in stable branches and other watcher projects. Job renames and consolidation were proposed, along with enabling tempest scenario jobs for stable branches and creating a new grenade job for upgrade testing. *Agreed*: - AI(dviroel): Job renames/consolidation: watcher-functional can be merged into other tempest jobs, watcher-tempest-actuator can be merged into strategies job, and ipv6 job should be integrated into other existing tempest jobs. Gate updates will occur after renaming and merging jobs. Backporting changes from master to stable branches is expected. - AI(dviroel): In watcher-tempest-plugin: replace tempest-functional with a tempest job that runs scenario tests for stable branch validation. - AI(chandankumar): A new grenade job to test upgrades between slurp releases and include more testing in existing jobs. - AI(sean-k-mooney): Propose a watcher job to run against OpenStack requirements project. Improving testing coverage for strategies by doing functional testing *Discussion*: A specification proposal and a detailed implementation plan for improving testing coverage for strategies through functional testing were presented. *Agreed*: - A phased approach will be taken: - AI(amoralej): 1st phase: API only GETs/POSTs. - 2nd phase: Adding decision-engine + Nova + Prometheus datastore. - 3rd phase: Adding Applier. Rally Testing in watcher *Discussion*: The current status of Rally testing in Watcher was reviewed, noting that the rally-task-watcher job runs but is not in the Watcher repository. Missing functionalities were identified, such as the inability to pass audit template scope and parameters, lack of auto-triggering, and no support for event, continuous audit, action plans, and actions. *Agreed*: - AI(chandankumar): Move rally-openstack watcher plugin code to watcher repo - AI(chandankumar): Add periodic job to run rally jobs - Revisit this topic in future as we progress on scaling watcher CI Watcher-dashboard improvements *Discussion*: Improvements to the Watcher dashboard were discussed, including adding auto-page refresh for audit/action plan status, a start button for action plan details, and options for bulk archiving. Dashboard testing using the Django test framework and Playwright was also covered. *Agreed*: - Create wishlist bugs or blueprints to track dashboard improvements. - AI(chandankumar): Check with TC regarding the usage of pytest to improve wording and proceed with integration tests implementation - AI(reviewers): Get the spec https://review.opendev.org/c/openstack/watcher-specs/+/963438 merged. - A spec will be required for the audit and action plan bulk archive feature. The future of datamodel list API *Discussion*: The utility of the datamodel list API, beyond tempest tests, was questioned. The possibility of freezing the API with existing content to avoid microversion bumps for new instance/node updates was raised. The addition of new storage models (storage and baremetal) was also discussed. *Agreed*: - Do NOT extend the API to support additional models. - Defer the removal of datamodel list (compute model) to future discussions, but for now, do not extend it further, even if new fields are added to model elements. - AI(dviroel): Add test to avoid new API changes in datamodel list. Eventlet Removal *Discussion*: Changes made in the Flamingo cycle regarding Eventlet removal were reviewed.The need for a collector sync timeout for threading mode and refactoring the action plan cancel workflow were discussed. *Agreed*: - AI(dviroel): Collector timeout topic: REST API calls should continue to have their own timeouts, and an event trigger can assist in stopping the overall sync process. Add a new config option for collector timeout should be considered. - Applier: stop killing threads when an action plan is canceled. We can keep the current behavior for evenlet but it will be a noop for threading mode (minimal impact for eventlet removal changes). - AI(dviroel): Set MAAS to deprecate after PTG. We will send an email to the ML to call for maintainers once again. (same AI in Future of datasources topic) Future of Noisy Neighbort Goal/Strategy *Discussion*: The deprecation of cache monitoring metrics in the kernel and Nova, which formed the basis of the current noisy neighbor strategy, was discussed. The need to replace this strategy and identify new metrics for contention (e.g., CPU steal, CPU pressure, IOWait) and noisy neighbors (e.g., CPU usage from low-priority instances) was explored. Instance priority mechanisms were also considered. *Agreed*: - Remove the current noisy neighbor strategy in 2026.2+ to allow deprecation to ship in a Slurp release. - AI(dviroel): a proof of concept for CPU steal/IOWait/other metrics is a nice to have, to replace current LLC monitoring metrics. - Use instance metadata for PoC, but consider different solutions for identifying/classifying workloads priorities, like tiering based on flavor extra spec information. Scaling Watcher *Discussion*: The limitations of running a single instance of the Decision Engine and Applier were discussed, with ideas for horizontal scalability. Scalability concerns were raised for different watcher resources: audits, actions and action plans. Some of the open issues that were discussed: - Centralized datamodel: it is independently managed by each decision-engine. Move the model from in-memory to memcached or the database was discussed. - ONESHOT audits are not a failover in a multiple-decision engine deployment. - When an applier dies, the action plan remains ONGOING and is only cancelled upon the applier restart. The main issue was identified as continuous audits being associated with a specific decision-engine. The concept of moving to an event-driven model with stateless decision engines and appliers was proposed, where data models would reside in the database or a shared data store. *Agreed*: - Fow now, instrument the decision-engine to measure the size of the model, and time taken to process notifications. - Keep current failover behavior for ONESHOT audits. - We could have a service monitor in the applier to reschedule PENDING action plans and cancel ONGOING ones, providing the proper status message. - There should be a way limit and set concurrency of actions in audits. In this cycle we will propose a mechanism setting them at system or audit level that covers all the strategies. Stacking Strategies *Discussion*: The possibility of having stacking strategies was brainstormed in this topic. This included ideas like sequential execution of multiple strategies, where a mutable cluster data model would be shared among them. This could result in a list of linked action plans, or result in merging all actions into a single action plan to avoid unnecessary steps. This discussion may be revisited soon, with a more detailed use case. *Agreed*: - Get back to this topic when we have more detailed use cases. Propose a spec to highlight the need of this feature in watcher. Please let me know if I missed something. Thanks! Assisted-By: Gemini -- Douglas Viroel - dviroel

1 0

[kolla][OpenStackAnsible] 2025.2 Flamingo release for cycle-trailing projects
by Thierry Carrez 04 Nov '25

04 Nov '25

Hi teams, This is a gentle reminder that the following projects with cycle-trailing release model haven't done their final 2025.2 Flamingo release yet: [kolla] ansible-collection-kolla kayobe kolla-ansible kolla [OpenStackAnsible] openstack-ansible-roles openstack-ansible Note that next week we'll ask for cutting stable/2025.2 branches, as kind of a Feature Freeze, 3 weeks prior the 2025.2 Flamingo Cycle-Trailing Release Deadline on December 4th, 2025 [1] (exactly one month away). [1] https://releases.openstack.org/gazpacho/schedule.html#g-cycle-trail Thanks in advance, -- Thierry Carrez (ttx)

1 0

[nova][ptg] 2026.1 Gazpacho PTG summary
by Rene Ribaud 04 Nov '25

04 Nov '25

Hello everyone, Last week was the PTG, thank you to all who joined and contributed to the discussions! I hope you enjoyed it and found it productive. Again, this cycle we had a packed agenda with active participation throughout the sessions. For the Nova sessions (Tuesday to Friday), we had an average of 15 to 20 participants per session. Attendance was slightly higher during the cross-project discussions, with an average of 25 to 30 people joining. You can revisit all notes and discussions on the Etherpad here: https://etherpad.opendev.org/p/r.9bac75a686ab0941572757b205c9415c Below is a summary of the topics and outcomes from our PTG discussions. I’ve tried to keep it as concise as possible, though we covered quite a lot during the week. **** Tuesday topics **** #### 2025.2 Flamingo Retrospective #### During the Flamingo cycle, 14 blueprints were accepted and 9 were fully implemented, resulting in a 64% completion rate. This is slightly lower than the 71% achieved during the previous Epoxy cycle. In addition, at least 26 bug fixes were merged during the cycle. Review & Process Feedback Eventlet Transition Plan, the migration continues to work as expected and remains well-coordinated. Release process was smooth with no major issues reported. Recognition to Kamil for his work on the conductor, and to Sean, Dan, and others for their consistent review efforts. ✅ Continue to prioritize the Eventlet removal as a key goal for the G cycle. Branch Opening Policy, some uncertainty remains about what can be merged between RC1 and GA, when master is technically open but still sensitive for late merges. Concerns were raised about backports and release stability. ✅ Allow merges on a case-by-case basis once the new master branch opens. ✅ Bauzas to propose a patch updating Nova contributor process <https://docs.openstack.org/nova/latest/contributor/process.html> <https://docs.openstack.org/nova/latest/contributor/process.html> Bug Triage, the number of untriaged bugs remains high (around 180). Efforts were noted, but time allocation and rotation remain challenging. The end-of-meeting triage format was found ineffective for real-time work, though still useful for discussing specific cases. ✅ Consider reviving a rotating triage roster if enough volunteers join. ✅ Keep triage discussions focused during the weekly meeting rather than doing live triage. Review Load, contributors noted increasing difficulty in finding time for reviews. Maintaining review velocity remains a cross-cycle challenge. ✅ Encourage feature-specific syncs or review sprints for high-priority areas. Feature Momentum, weekly syncs and structured updates help large features maintain progress. The VMware CI topic was cited as useful, though too many topics per meeting could cause overload. ✅ Keep dedicated weekly or bi-weekly syncs for major features (e.g. Eventlet removal). ✅ Limit meeting updates to 2-3 features per session. Review Tracking, the previous Etherpad tracker was not effective. However, having a central list remains important to avoid missing patches and to monitor review health. ✅ Discuss an external or simplified review tracker during the next meeting with more core reviewers. ✅ Keep the tracker short and up to date to maintain visibility. #### 2025.2 Flamingo Planning #### Hard spec freeze: December 4th Milestone 2 (M2): January 8th Feature Freeze (FF): February 26th Release: End of March / early April. The team discussed adjusting the timing of the spec freeze. A soft spec freeze was proposed for November 20th, giving three weeks after the PTG for contributors to submit specs. Two spec review days will be scheduled between the soft and hard freezes. Additionally, two implementation review days are planned: one around M2 for early landings, and another roughly two weeks before M3. ✅ Adopt the proposed plan, while staying flexible on a case-by-case basis. ✅ Soft spec freeze on Nov 20th, followed by two spec review days before Dec 4th. ✅ Two implementation review days: one near M2 and one two weeks before M3. ✅ A +2 on a spec implies reviewers commit to reviewing the corresponding implementation. #### Upstream meeting schedule #### ✅ Move the weekly upstream meeting to Monday at 16:00 UTC. ✅ Keep the slot fixed (no alternating or skipping weeks). ✅ Uggla to update the meeting schedule and cycle accordingly. #### Upstream bug triage follow up #### The team discussed how to better organize bug triage follow-up for the Gazpacho cycle. A proposal was made to create a small group of volunteers who would receive a few bugs to triage each week. Each volunteer would handle up to three bugs, distributed by Uggla. During the weekly upstream meeting, the team will check whether a dedicated Q&A session is needed to discuss specific bugs. If required, such a session will be scheduled every two weeks, ideally right after the upstream meeting. Otherwise, discussions will take place within the regular meeting. ✅ The team agreed to give this approach a try in the next cycle. The overall sentiment seemed favorable, though details will likely need adjustment as we go. #### Eventlet removal #### Significant progress was made since Flamingo. In Flamingo, n-api, n-metadata, and n-sch could already be switched to native threading via an environment variable, and the nova-next job runs those services without Eventlet. n-cond was nearly ready but missed feature freeze due to a late futurist bug, which has since been fixed and released. A py312-threading tox target and a Zuul job already validate a large part of the unit tests without Eventlet. In early Gazpacho, native threading for the conductor has successfully landed. Planned tasks for Gazpacho - Add native threading support for n-novncproxy and other proxies. - Add native threading support for n-compute. - Run all unit and functional tests in both threading and Eventlet modes, keeping small exclude lists where needed. - Conduct scale testing using the fake driver, possibly extended to the libvirt driver. - Switch n-api, n-metadata, and n-sch to native threading by default, keeping Eventlet as fallback. - Introduce a nova-eventlet (legacy) CI job to ensure backward compatibility. - Keep nova-next as the only job testing conductor, novncproxy, and compute with threading until the H cycle. - Fix bugs reported after Eventlet removal. - After Eventlet removal, migrate from PyMySQL to libmysqlclient for better DB performance. ✅ Kamil volunteered to handle the novncproxy migration. ✅ Start with nova-compute migration first to build confidence. ✅ Switch the default to threading as early as possible in Gazpacho. ✅ Add a dedicated Eventlet CI job to continue testing legacy mode. ✅ Use the hybrid plug job to test Eventlet mode even for services switched to threading by default. ✅ Keep the work independent, but document the known issue with long-running RPC calls. #### Long-Running Sync REST API Calls #### The team discussed how long-running synchronous REST API actions (like volume or interface attach) can block nova-api threads once Eventlet is removed. With native threading, the limited number of threads makes blocking calls more costly, unlike Eventlet which could spawn many lightweight greenlets. This work is closely related but independent from the Eventlet removal effort. Dan started a spec on the topic, and it may be split into two (volume and interface attach). Detach operations are already async, and Manila shares follow a similar model. ✅ Introduce a new microversion to keep backward compatibility. ✅ Convert volume and interface attach to async operations under that microversion. ✅ Coordinate with Rajesh’s "show finish_time" ( https://review.opendev.org/q/topic:%22bp/show-instance-action-finish-time%22 ) work to avoid race conditions. ✅ Dan and Johannes to update the spec. ✅ Further investigation is needed to determine if WSGI or API tuning could help mitigate blocking. #### vTPM Live Migration #### The team reviewed how to handle TPM secret security policies during instance operations. Changing the assigned policy during resize is not supported, as it adds complexity and can lead to image/flavor conflicts. Rebuilds are already blocked for vTPM instances, so once a policy is set via resize, it remains locked in. Existing instances from previous releases are unaffected. ✅ Do not allow changing the TPM secret security policy after assignment. ✅ Remove the option to select the policy from the image for simplicity. ✅ Default policy is “user”, but compute nodes support all policies by default. ✅ Document in the spec and release notes that deployers must define flavors with hw:tpm_secret_security if they want to enable this. ✅ Mention that [libvirt]supported_tpm_secret_security = ['user', 'host', 'deployment'] can be adjusted by operators. **** Wednesday topics **** #### CPU Comparison During Live Migration #### The team revisited the CPU compatibility check between source and destination hosts during live migration. If skip_cpu_compare_on_dest is enabled, some migrations may fail due to missing pre-checks; if disabled, the check can sometimes be too strict. The original goal is to avoid migrations to nodes running with QEMU emulation, which would cause serious performance issues. ✅ Include getDomainCapabilities in the Nova pre-check to improve accuracy. ✅ Move the configuration flag from workaround to the libvirt section. ✅ Document potential unsafe edge cases so deployers can choose between the safer (Nova) or more permissive (libvirt-only) approach. ### Start cross session with Cinder ### #### NFS / NetApp NFS Online Volume Extend #### The team discussed adding online volume extend support for NFS and NetApp backends. Instance operations (like shutdown or migration) should be blocked during the extend process, and any new task_state must stay compatible with existing microversions. ✅ Avoid using the event API, as it’s meant for fast operations. ✅ Introduce a dedicated API for this feature to manage versioning and states. ✅ Consider making the Cinder call synchronous for better control. ✅ Konrad will update the spec in this way. #### Hard-Coded io=native Setting for Cinder Backends #### The team revisited the hard-coded io=native driver setting used for Cinder volume backends (NFS, FC, and iSCSI). This code dates back nearly ten years and has recently caused performance issues and guest hangs in some environments. The original reason for enforcing io=native is unclear. ✅ No one seems to know the reason for this original choice ✅ Move the configuration to a standard libvirt configuration option. ### End cross session with Cinder ### #### Preserve NVRAM After Reboots and Migrations #### The team discussed the proposal to preserve NVRAM data across instance reboots and migrations. The feature is ready for review, pending available reviewer bandwidth. ✅ Request a definitive answer from libvirt regarding file permission handling through a bug report. ### Start cross session with Ironic/Cinder ### A more complete summary of this joint session will be provided by the Ironic team, as they can better capture the discussions and decisions made. However, the Nova PTG notes still include a few relevant takeaways and references for those interested. ### End cross session with Ironic/Cinder ### ### Start cross session with Manila ### The teams discussed testing and integration plans between Nova and Manila. Testing through Tempest was considered challenging due to configuration complexity and potential circular dependencies. Support for CephFS and NFS, hot attach, and live migration with newer OS versions was identified as a goal. ✅ Manila will draft initial UX and workflow details to share with Nova for review. ✅ Add a backlog spec in the Nova repository to track cross-team work. ✅ Manila contributors may help with open SDK and client patches as needed. ✅ Hot attach and live migration support are valuable goals but will need explicit demand and prioritization to move forward. ### End cross session with Manila ### ### Start cross session with Neutron ### A more complete summary of this joint session will be provided by the Neutron team, as they can better capture the discussions and decisions made. However, the Nova PTG notes still include a few relevant takeaways and references for those interested. ### End cross session with Neutron ### **** Thursday topics **** #### Correct Firmware Detection for Stateless Firmware and AMD SEV/SEV-ES #### The team discussed improving firmware detection for stateless firmware and AMD SEV/SEV-ES. Recent QEMU and libvirt versions now include firmware descriptor files that expose these capabilities, allowing libvirt to automatically select the right firmware without Nova duplicating that logic. The group agreed that leveraging libvirt’s detection is the better long-term approach. To avoid regressions, Nova should continue to preserve existing firmware for running instances during hard reboots, while new instances will rely on libvirt’s detection from the start. ✅ Use libvirt’s firmware detection instead of maintaining custom logic in Nova. ✅ Preserve the existing firmware for current instances on hard reboot. Let libvirt select firmware for new ones. ✅ Takashi will write a spec describing the approach and detailing the upgrade path. ✅ He will also check UEFI/stateless firmware tests in CI and run local SEV/SEV-ES tests. #### ROM-Type Firmware Support #### The team continued the discussion on firmware selection, focusing on ROM-type firmware used by AMD SEV-SNP, Intel TDX, and future Arm CCA. Since recent libvirt versions can automatically select the appropriate firmware and handle SMM when needed, Nova no longer needs to manage this logic directly. ✅ Skip further work in Nova and rely on libvirt’s firmware auto-selection mechanism. #### AMD SEV-SNP Support #### The team discussed initial plans for SEV-SNP support, which depends on firmware and requires recent QEMU (≥9.2) and libvirt versions. Work may be postponed to the 2026.2 cycle due to these dependencies. For SEV-SNP, there is a need to provide hostData, an immutable and attested field (up to 32 bytes) that can be set by Nova or external tools. Using Nova metadata for this purpose was ruled out. ✅ Do not use Nova metadata to provide SEV-SNP host data. ✅ The instance POST API could be extended to allow providing this information. ✅ Takashi will write an initial spec, keeping the design generic for both SEV-SNP and TDX. #### Generalize SEV / SEV-ES Code #### The team reviewed the proposal to generalize the existing SEV/SEV-ES code in preparation for future Confidential Computing architectures such as Intel TDX and Arm CCA. The work focuses on refactoring internal Nova code to make memory encryption handling more generic, without changing any user-visible behavior or API. ✅ Treat this as a code refactoring only (no external impact). ✅ Ensure it does not conflict with Takashi’s ongoing work. ✅ Implementation can proceed as a specless blueprint. ✅ No Tempest job available. Manual validation is acceptable, ideally with screenshots or logs. ✅ Note: It’s possible to run Tempest manually using a flavor requesting SEV/SEV-ES to verify correctness. #### Arm CCA Support #### The team discussed the roadmap for Arm CCA enablement in Nova. Upstream dependencies include Linux Kernel (Dec 2025), QEMU (Feb 2026), and libvirt (Mar 2026), with full availability expected around Ubuntu 26.04 (Apr 2026). As a result, development and testing in OpenStack are expected to start during the 2026.2 cycle. ✅ Features cannot merge until support is available in official distributions (not custom kernels). ✅ CentOS Stream 10 may serve as an early test platform if it gains CCA support before Ubuntu 26.04. ✅ Specs or PoCs can still be prepared in advance to ease future inclusion. ✅ Once libvirt support lands, the team will review the spec, targeting early in the H (2026.2) cycle. #### Show finish_time in Instance Action Details #### The proposal adds a finish_time field to the instance action show API, along with matching updates in the SDK and client. Some review comments still need to be addressed before re-proposing the patch for the G release. ✅ No objection to re-proposing the patch for Gazpacho (G). ✅ The existing spec remains valid. ✅ Gmaan will review previous comments to help move the implementation forward. ### Start cross session with Glance ### A more complete summary of this joint session will be provided by the Glance team, as they can better capture the discussions and decisions made. However, the Nova PTG notes still include a few relevant takeaways and references for those interested. ### End cross session with Glance ### #### Periodic Scheduler Update as Notification #### The proposal suggests exposing Nova’s periodic resource tracker updates as optional versioned notifications. This would help services like Watcher obtain a more complete and up-to-date view of compute resources, including NUMA topology and devices not yet modeled in Placement. While there are concerns about notification stability and data volume, the team agreed it could be useful for cross-service integrations. ✅ Support the idea in principle. ✅ Be mindful of the volume of data included in notifications. ✅ Sean will prepare a spec proposal detailing the approach. #### Resource Provider Weigher and Preferred/Avoided Traits #### The proposal introduces a resource provider weigher to influence scheduling decisions, with a longer-term goal of supporting preferred and avoided traits. This would allow external services, such as Watcher, to tag compute nodes (e.g., with CPU or memory pressure) and guide the scheduler to favor or avoid specific hosts. ✅ There are concerns about validating the weigher’s behavior at scale, ensuring it works correctly with a large number of instances. ✅ Continue developing this approach. ✅ Improve the test framework, despite existing challenges. ✅ Add Monte Carlo–style functional tests to validate behavior in complex, non-symmetric scenarios. #### Proxying OVH’s Monitoring-Aware Scheduling #### The team discussed OVH’s proposal to enhance scheduling decisions by integrating external monitoring data. The idea is to add a filter or weigher that delegates its logic to an external plugin, allowing operators to plug in custom metrics (e.g., Prometheus, InfluxDB) without modifying Nova directly. While the use case is relevant, existing out-of-tree filters and weighers already allow similar integrations. One of the main challenges identified was how to share and maintain such code consistently across the community. ✅ Current Nova interfaces likely already support this use case. ✅ Proposal to create a dedicated repository on OpenDev for sharing and maintaining custom filters and weighers. **** Friday topics **** #### LY Corp – Graceful Shutdown Proposal #### The team discussed LY Corp’s proposal to implement graceful shutdown handling in Nova. The goal is to stop accepting new RPC requests while allowing in-progress operations, such as instance boots or live migrations to complete safely. Different designs were compared, including stopping RPC listeners or using the upcoming oslo.messaging HTTP driver, which can handle clean shutdowns more reliably. The consensus was that the complete solution must involve oslo.messaging, allowing Nova services to dynamically subscribe or unsubscribe from topics. This approach also implies an upgrade impact, requiring versioned changes to compute and scheduler topics. ✅ The current proposal needs further work, as live migration cases were not yet considered. ✅ Gmaan will continue investigation and refine the approach based on oslo.messaging improvements. ✅ A revised spec will be submitted once ready. ✅ Gmaan confirmed commitment to follow up and lead this feature. #### Offline VM Migration Using HTTP-Based File Server #### The team discussed a proposal to enable offline VM migration using an HTTP-based file server. The preferred approach is to use WebDAV, which provides a standard protocol and existing server implementations. Nova itself will not host the web server and will be restricted to paths under /var/lib/nova. ✅ Use WebDAV as the preferred protocol. ✅ Avoid introducing non-standard protocols in Nova. ✅ Nova will not spawn or host the web server directly. ✅ Define a URL template in configuration for the remote filesystem driver (e.g., remotefs_url = https://%(host)s:9999/path/to/dav). ✅ Add DevStack support to test the feature in CI. #### PCI and VGPU Scheduling Performance in Placement The team revisited the performance issues with PCI and VGPU scheduling in Placement. Two workaround sets have already been implemented to reduce the number of valid and invalid candidates, but the core scalability problem of the GET /allocation_candidates query remains, especially in large, symmetric provider trees. A long-term constraint solver approach is under consideration, and the discussion will continue once more data is available from current deployments. ✅ Keep the current workarounds active and gather feedback over the next six months. ✅ Nova-next may run with these settings enabled to collect early results. ✅ Revisit the topic and defaulting decisions at the next PTG. ✅ Keep the issue open for urgent improvements if needed before the next cycle. #### Multithread and Multiqueue Support for Libvirt #### The team discussed adding multithread and multiqueue support in Nova for libvirt-based instances. While QEMU already enables multiqueue for virtio-blk and virtio-scsi by default, the main focus is now on IOThread support and improving parallelism during I/O and live migrations. ✅ Enable IOThreads with one thread per device by default (handled as a specless blueprint). ✅ virtio-blk and virtio-scsi specs are parked. ✅ Cancel the multiqueue work, since QEMU now manages it natively. ✅ The parallel migration blueprint is approved as specless. ✅ The earlier proposed spec will be abandoned in favor of this simplified path forward. #### AZ-Aware Scheduling (Soft Anti-Affinity) #### The team discussed improving availability zone–aware scheduling by introducing a soft anti-affinity policy for server groups. ✅ The overall direction is good, but the spec still needs more work. ✅ The team is broadly supportive of continuing in this direction. ✅ A spec will be proposed by Dmitriy. #### NUMA-Aware Placement (CloudFerro Proposal) #### The team discussed CloudFerro’s proposal to enable NUMA-aware scheduling in Placement, based on the old Ussuri spec. The goal is to represent NUMA nodes as resource providers to allow better locality handling for CPU and memory resources. However, this raises potential performance concerns, especially when combined with PCI in Placement, as both increase candidate permutations. ✅ Ensure NUMA and PCI in Placement work together correctly before expanding scope. ✅ Do not move PCI devices under NUMA subtrees yet. ✅ Add functional tests to validate the combined behavior. ✅ Consider extending CI to run on hosts with real NUMA topology. ✅ Enable NUMA awareness in nova-next (single NUMA node for now). ✅ Investigate with the infra team the possibility of adding dual-NUMA test nodes. ✅ Improvements to Placement’s group_policy remain out of scope for this work. ✅ The team is happy with the current direction and looks forward to future patches landing in master. #### WSGI Script Removal #### The team discussed removing the legacy wsgi_script support from Nova. No objections were raised, and no spec is required. ✅ Proceed with the removal, the team is aligned and ready to move forward. #### Improving Cyborg Support #### The team discussed reviving Cyborg integration efforts in Nova. Several aspects remain unfinished, including proper mdev GPU XML generation, support for additional device buses (block, NVMe, CXL, USB), and handling ownership overlap between Nova and Cyborg in Placement. The plan is to resume this work gradually, starting with the most mature components. ✅ Restart the Cyborg–Nova integration effort. ✅ Split the work into multiple specs, as each part is complex enough to warrant separate discussion. ✅ Focus first on mdev support, then extend to other buses (block, NVMe, etc.). ✅ Investigate Placement ownership to avoid inventory conflicts between Nova and Cyborg. If you've read this far, thank you! 🙏 If you spot any mistakes or missing points, please don't hesitate to let me know. Best regards. René.

2 2

[publiccloud-sig] Public Cloud SIG meeting d.d. 5 November
by Kees Meijs | Nefos 04 Nov '25

04 Nov '25

Hello Stackers, Tomorrow (that's 5 November) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:00 hrs UTC (09:00 hrs CET) until 08:45 hrs UTC (09:45 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0

[ironic][kolla][kolla-ansible] Missing DNS config during introspection
by Thomas Sell 04 Nov '25

04 Nov '25

Hey everyone, I'm facing a weird issue when trying to enroll baremetal compute hosts into Ironic using the self-enrollment/discovery method. Our Openstack is running 2025.1 and is based on Kolla-Ansible/Kayobe. What I'm seeing: - New hosts iPXE boot into IPA ramdisk. - IPA does its thing, gathering information. - IPA tries to report back to http://{{ kolla_internal_fqdn }}:5050 - The API call fails because no nameservers are available. I've tried to figure out where the IPA ramdisk is supposed to get its DNS config from and could not. There are no dhcp-options set in Ironic's dnsmasq.conf and looking at the Ansible template for this file, I believe this is by design. Inside the ramdisk /etc/resolv.conf is empty, yet IPA is configured to call-back to a FQDN, not an IP. I'm a bit puzzled about how this is supposed to work. We're using IPA images downloaded from https://tarballs.openstack.org. Do I need to build my own image? I also cannot find any mention of a separate DNS config for Ironic introspection in the documentation. Any help or hints are appreciated! Best, Thomas

3 3