- openstack-discuss - lists.openstack.org

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

05 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

[puppet] Retiring puppet-vitrage
by Takashi Kajinami 03 Dec '25

03 Dec '25

Hi, Some of you might be aware of this, but the vitrage project was marked inactive during this cycle[1] due to lack of maintainers. This means that we don't expect we have its 2026.1 release. Because our puppet modules are tightly related to the packages of each OpenStack releases, provided by distributions such as RDO or Ubuntu(or UCA), and now we may not expect that vitrage packages are available in 2026.1 packages of these distributions, I now propose retiring puppet-vitrage, the module to deploy and manage vitrage. Please let me know if you have any concern. If I hear no objection, I'll start the formal retirement process. Thank you, Takashi [1] https://review.opendev.org/c/openstack/governance/+/963227 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

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 03 Dec '25

03 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

[publiccloud-sig] Public Cloud SIG meeting d.d. 3 December
by Kees Meijs | Nefos 02 Dec '25

02 Dec '25

Hello Stackers, Tomorrow (that's 3 December) 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

[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

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

28 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 28 Nov '25

28 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 26 Nov '25

26 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 25 Nov '25

25 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 24 Nov '25

24 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