- openstack-discuss - lists.openstack.org

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