- openstack-discuss - lists.openstack.org

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

01 Dec '25

Hello Stackers, We're seventeen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. On Thursday this week, we'll be wrapping up releases for "trailing" deliverables concerning the OpenStack 2025.2 "Flamingo" release. In the past week, the OpenStack Technical Committee merged a couple of resolutions [2]. The first of these concerned Special Interest Groups in OpenStack [3]. You're probably aware that we began auditing and cleaning up stale information with respect to SIGs. We captured that work in a resolution to formalize the governance update, as governance of the SIGs has evolved over the past few years and some things needed clarification. The second resolution was about the retroactive steps we've taken to advertise the continued maintenance of os-net-config outside of the OpenStack community. We're glad to see the current maintainers taking the steps highlighted in the resolution, and would like to use these artifacts to inform users of the current state of the project. Finally, we made major progress on the retirement of the Monasca project. All deliverables for the project were marked retired in the past week, and we'll proceed with cleaning up references in our documentation and elsewhere. The TC would welcome the development and maintenance of the Monasca project outside of OpenStack, since we discovered users and their use cases while we were mulling this retirement. Eventually, the decision stemmed from the lack of interest to meet the standards of maintenance and release delivery within the OpenStack community. We are looking for volunteers to serve as election officials [4] for the TC and PTL elections that will be held in the next year. If you're interested in serving, please let me know, or chime in on OFTC's #openstack-election channel. The TC and the community would be grateful for your service! === Weekly Meeting === The last weekly meeting of the OpenStack TC was held on November 25th, 2025 in OFTC's #openstack-tc IRC channel [5]. We discussed the resolution on the os-net-config handover, and no objections were raised against completing the process. We also addressed the concerns regarding our current FIPS compliance goal. Our plan is to return the goal to a "proposed" state while the team redefines testing requirements and identifies resources to commit to the goal. We also discussed the changes needed in our documentation to preserve PTL appointment history even as projects transition between governance models. We noted that the Monasca cleanup was nearing completion with adjustments made to validation scripts to ignore legacy license files. Work continues on removing passlib from global requirements in tangential support of the Post-Quantum Cryptography initiative [6]. We addressed an impasse regarding tracking metrics (using Google Analytics) in OpenStack Manuals [7], deciding to merge pending changes now and treat the removal of tracking code as a separate, subsequent task if necessary. Finally, we discussed the Python Project Testing Interface (PTI) in the context of pytest usage for Horizon plugins [8]. The consensus was that while consistency is important, pytest is acceptable if it supports key requirements like parallel execution and generating standard subunit output, and the PTI documentation may need updates to reflect valid use cases beyond stestr. The next meeting of the OpenStack TC is on Tuesday, December 2nd, 2025 at 1700 UTC. This meeting will be hosted on the #openstack-tc channel on OFTC. Please find the meeting's agenda on its wiki page [9]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Ignore monasca repos for legacy validation | https://review.opendev.org/c/openstack/governance/+/968268 ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 === 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 TC Resolutions: https://governance.openstack.org/tc/resolutions [3] SIGs in OpenStack: https://governance.openstack.org/tc/reference/sigs/ [4] OpenStack Election Officiating: https://governance.openstack.org/election/#election-officials [5] TC Meeting IRC Log, Nov 25 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-25-17.00.html [6] Supporting PQC in OpenStack: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] Google Analytics in OpenStack Manuals: https://review.opendev.org/c/openstack/openstack-manuals/+/905614 [8] pytest in the PTI: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [9] TC Meeting Agenda, Dec 2 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic] iRMC hardware type deprecation in 2026.1
by Jacob Anders 01 Dec '25

01 Dec '25

Hi All, The iRMC hardware type (for Fujitsu PRIMERGY servers) has been deprecated in the 2026.1 cycle and is scheduled for removal from master in 2026.2. The driver will remain in stable and unmaintained branches to fulfill our support obligation. The iRMC driver has been unmaintained for an extended period. Third Party CI stopped working in 2019 and our attempts to contact the provider and have it resume have been unsuccessful. Without CI coverage we can't be confident the driver works with current Ironic releases. This deprecation affects the iRMC hardware type and all its interfaces (bios, boot, inspect, management, power, raid, and vendor). If you're currently using iRMC in your deployment, now is the time to start planning migration to another hardware type. If the hardware supports it, using Redfish hardware type may be an option. Alternatively, the legacy IPMI driver may be of assistance, however may be limited to basic functionality. If you need help or have concerns about this change, please reach out. If your organization is interested in maintaining this driver going forward (including providing CI), we'd be happy to work with you. The deprecation commit with full details can be found here: https://opendev.org/openstack/ironic/commit/7d050f6ae227beb87bb810148a2a0ae… Best Regards, Jacob Anders on behalf of Ironic Community

1 0

[neutron] Bug deputy Nov 24 - Nov 30
by Elvira Garcia Ruiz 01 Dec '25

01 Dec '25

Hi folks! Here you have the list of bugs reported for Neutron during last week. Critical ---------- - https://bugs.launchpad.net/neutron/+bug/2132355 Due to the eventlet migration work networking-bagpipe unit tests are failing Fix commited by Lajos Katona https://review.opendev.org/c/openstack/networking-bagpipe/+/968303 High ------- - https://bugs.launchpad.net/neutron/+bug/2132348 [DEFAULT] metadata_workers and metadata_backlog are ignored Fix proposed by Takashi Kajinami https://review.opendev.org/c/openstack/neutron/+/968242 - https://bugs.launchpad.net/neutron/+bug/2132982 [OVN] Missing ML2 extension 'qos-bw-minimum-ingress' Fix proposed by ralonsoh https://review.opendev.org/c/openstack/neutron/+/968450 Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2132342 OVN LB / FIP PF does not reply to ARP when VIP is from different subnet than router Unassigned. - https://bugs.launchpad.net/neutron/+bug/2132977 [OVN] Allowed address pair with CIDR doesn't mark ports as "virtual" Fix proposed by Slawek https://review.opendev.org/c/openstack/neutron/+/968812 - https://bugs.launchpad.net/neutron/+bug/2133212 [S-RBAC] Regular user can't never send project_id in request body, even with custom policy rules which allows that Assigned to Slawek Wishlist ---------- - https://bugs.launchpad.net/neutron/+bug/2132382 [RFE] Refactor the SR-IOV agent to use the oslo.service launcher Unassigned Best regards! Elvira

1 0

[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 13 Nov '25

13 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