May 2026 - openstack-discuss - lists.openstack.org

[tc][keystone][all] Proposal for Rust as an official OpenStack language
by JP Jung 12 May '26

12 May '26

Hi all, This is a formal request to add Rust as a supported language in the OpenStack ecosystem, following the two-step process defined in [Requirements for language additions](https://governance.openstack.org/tc/reference/new-language-requi…. This email covers Step 1 (use case analysis). We want to hear your thoughts before we bring a resolution to the TC. **The problem: Keystone is a scaling blocker** Keystone sits in the hot path of every OpenStack API call. Every request to Nova, Neutron, or Swift requires a token validation. For large CSPs, this "Identity Tax" is no longer negligible; operators are telling us directly that Keystone's throughput and latency are a scaling problem. We tried the Python options: * **Eventlet** is being removed community-wide (the Eventlet Removal Initiative is a major Hibiscus effort, and for good reason). * **asyncio** helps with I/O-bound work, but token validation, policy evaluation, and cryptographic operations are CPU-bound. The GIL still limits you to one core of real execution per process. * **More workers** is what operators do today (typically one per CPU core), but each worker consumes significant memory. At edge sites, this matters. * **WSGI cannot do application-level mTLS.** New identity features like mutual TLS require Keystone to validate client certificates directly. Under the WSGI model, TLS terminates at the reverse proxy & Keystone never sees the certificate. Forwarding cert data via headers is [fragile and vulnerable to injection](https://github.blog/security/vulnerability-research/mtls-when-certificate-authentication-is-done-wrong/). Rust with native TLS gives Keystone full control of the connection, which operators in regulated environments (PCI-DSS 4.0, NIST 800-207) need. Profiling shows that the CPU-bound parts of Keystone, token signing, policy checks, JSON serialization, account for most of the request latency. These are exactly the operations where Python is 10x-100x slower than compiled code. **Why Rust specifically (and not Go)** Go was approved in 2017 for Swift ([resolution](https://governance.openstack.org/tc/resolutions/20170329-golang…) We looked at it, but Go is a poor fit for Keystone: * Go's runtime and GC are incompatible with Python's process model. Using Go would force a hard service split \-- two binaries, two processes, doubled infrastructure. Rust via [PyO3](https://pyo3.rs/) integrates directly into existing Python processes. No service split required. * Go still has GC pauses (P99 tail latency). Rust has no GC at all, response times are deterministic, which matters when you are at the root of every request chain. * Go's weak enum types cannot enforce exhaustive handling of auth states at compile time. Most Keystone CVEs are logic bugs (forgotten checks, unhandled cases), not memory bugs. Rust's exhaustive pattern matching and `Option<T>` make it physically impossible to ship code that forgets an authorization check, it will not compile. This is not theoretical. The Python ecosystem itself is moving to Rust: `cryptography, pydantic, ruff` all have Rust cores behind Python interfaces. The pattern works. **What already exists** Unlike Go in 2016, Rust already has a significant footprint in OpenStack: * [**Keystone-NG**](https://openstack-experimental.github.io/keystone/): 100,000+ lines of Rust, partial reimplementation of Keystone identity flows. Runs in parallel with Python Keystone. New features: native WebAuthn/passkeys, reworked federation, OIDC, JWT login, workload authorization (service accounts, similar to AWS STS / GitHub Actions OIDC). Benchmarks show 10x-1000x throughput improvement on the same hardware. Presented at the [OpenInfra Summit in Paris](https://www.youtube.com/watch?v=0Hx4Q22ZNFU) and discussed at the [April 2025 PTG Keystone session](https://lists.openstack.org/archives/list/openstack-discuss@lists.…. * [**OpenStack Rust SDK and CLI**](https://github.com/gtema/openstack): 500,000+ lines of code auto-generated from OpenAPI specs, production-ready. * **Official [codegenerator support](https://docs.openstack.org/codegenerator/latest/rust_sdk.html)** for Rust SDK and CLI: the infrastructure investment is already there. * [**rust-openstack SDK**](https://github.com/dtantsur/rust-openstack): API consumption library, around since 2018\. The Rust Foundation is an Associate Member of the Open Infrastructure Foundation. **Scope** This is deliberately limited: * **Now:** Keystone identity service (token validation, auth flows, modern identity protocols). * **Later:** Other performance-critical components where Python is demonstrably insufficient. * **Not proposed:** Rewriting all of OpenStack in Rust. Python remains the primary language for the vast majority of our code. **Step 2 pre-work** We learned from the Go proposal's initial rejection in 2016 (the "where is goslo?" problem). We are committed to the cross-project work required for Step 2: * **Shared libraries:** `openstack-rust-common` crates providing oslo.config-compatible configuration parsing and oslo.log-compatible logging, so Rust components behave like Python ones from an operator's perspective. * **CI/CD:** Zuul jobs for Rust (clippy, rustfmt, cargo test, cargo doc). We will work with the Infrastructure team. * **Distribution:** Cargo crates on crates.io, container images, and PyO3 bindings for the incremental path. * **Vulnerability management:** cargo-audit in CI, RustSec advisory monitoring, integration with the OpenStack CVE process. * **Documentation:** Rustdoc generation, Sphinx integration, publication on docs.openstack.org. We are ready to invest the time for the organizational work should this request be accepted. Finally, the regulatory landscape is moving toward memory safety as a baseline. CISA and NSA have urged software manufacturers to publish [memory safety roadmaps](https://www.cisa.gov/case-memory-safe-roadmaps) and transition security-critical code to memory-safe languages. The EU [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), effective December 2027, requires secure-by-design practices for all products with digital elements. Neither mandates a specific language, but both create momentum that aligns with this proposal. **What we are asking** Review and discuss this use case. If the TC agrees the justification is sufficient, we will submit a formal resolution for a vote (Step 1), and proceed with the Step 2 requirements. I look forward to your feedback, supportive, skeptical, or otherwise. JP Jung

2 1

Subject: [neutron][2026.1] DHCP agent state report timeouts (MessagingTimeout) with neutron-rpc-server split services
by Jay See 12 May '26

12 May '26

Hello OpenStack community, I am seeing recurring Neutron DHCP state-report RPC timeouts after upgrading to OpenStack 2026.1 from 2025.1 in an HA deployment. Environment: - OpenStack: 2026.1 (split Neutron services: neutron-api and neutron-rpc-server) - HA controllers: 3 nodes - RabbitMQ cluster: 3 nodes - Percona Xtra DB Cluster: healthy - Rabbit transport_url set to individual broker IPs (did not work VIP also) Observed error from neutron-dhcp-agent: - oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message What we already checked: - RabbitMQ cluster health is good (no alarms/partitions). - AMQP connectivity/authentication is successful. - Queue backlog is near zero (messages_ready/unacked mostly zero). - transport_url is configured with all 3 RabbitMQ node IPs. (VIP didnt work, changed it) - We removed broad HA policy and tested more restrictive policy behavior. - Despite this, DHCP state report timeouts continue intermittently. - In Rabbit queue listing, dhcp_agent and dhcp_agent.<host> show consumers = 0 after restart windows. Question: - What is the recommended troubleshooting path for 2026.1 split Neutron services when DHCP report_state RPC calls time out but Rabbit/Galera appear healthy? - Are there known issues with neutron-rpc-server consumer registration, eventlet warnings, or packaging/systemd behavior in 2026.1? I can provide full logs and config snippets if needed. Some of the logs are here: https://pastebin.com/60WyCkiD Thanks in advance. Best regards, Jay. -- P *SAVE PAPER – Please do not print this e-mail unless absolutely necessary.*

2 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.2/R-20)
by Goutham Pacha Ravi 11 May '26

11 May '26

Hello Stackers, We're 20 weeks away from the date of the coordinated release of OpenStack 2026.2 "Hibiscus" [1]. This week is milestone-1 of this release. This is a bug targeting milestone for most project teams. The Secure RBAC community goal is picking up steam. Ghanshyam Maan (gmaan) posted a plan to remove the enforce_scope configuration option by milestone-2 (July 3) [2]; five projects still have it disabled: Cinder, Tacker, Aetos, Aodh, and Barbican. They all could need work to help this transition. That removal is a significant milestone for the goal, since it means every OpenStack service would be enforcing proper scope checks by default. Beyond that, gmaan also kicked off a conversation about a global "reader" persona [3], a system-level read-only role that could give operators cross-project audit access without handing out admin credentials. This won't be part of the current SRBAC goal, but the interest from operators and developers alike is a good sign. We hope to wind down the Secure RBAC community goal during this release. The OpenStack Vulnerability Management Team has been working with various projects on addressing new vulnerabilities. If you'd like to stay connected on security in OpenStack, the chatter happens on OFTC's #openstack-security channel, in addition to this mailing list. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on May 5, 2026 [4]. We confirmed that Venus and Vitrage are proceeding towards retirement and deprecation respectively; cleanup patches for Venus [5] are posted and need reviews. The PQC Migration popup team proposal [6] has merged. The pop up team will form and make progress based on the feedback gathered on this mailing list and the virtual PTG. We then discussed Sylvain Bauza's (bauzas) TaCT SIG proposal to add an agentic-workflows repository [7], which has also since merged. The SIG would house resources for using LLM-based tools effectively and safely in OpenStack development. bauzas separately abandoned his AGENTS.md community goal proposal after it received pushback on Gerrit; the prevailing view is that sharing agentic tooling should be opt-in and informal rather than a mandated goal. The value is in sharing and revealing tribal knowledge and improving contributor documentation, which helps humans and tools alike. In open discussion, Michal Nasiadka (mnasiadka) shared progress on governance patches to add an "inactive" badge for projects, which will be handy as we work through project health tracking. We also noted that Zun merged enginefacade rework recently, but remains a one-person project. Something to keep an eye on. The next meeting of the OpenStack TC is Tuesday, May 12, 2026, at 1700 UTC. This meeting will be hosted on the #openstack-tc channel on OFTC. Please see the agenda on the meeting's wiki page [8]. I hope to see you there. === Governance Proposals === ==== Merged ==== - Add agentic-workflows to TaCT SIG | https://review.opendev.org/c/openstack/governance/+/984958 - Add PQC Migration popup team | https://review.opendev.org/c/openstack/governance/+/982062 ==== Open for Review ==== - Retire Venus Project | https://review.opendev.org/c/openstack/governance/+/981959 - Deprecate vitrage project | https://review.opendev.org/c/openstack/governance/+/982869 - [EOL]: Retire VirtualPDU | https://review.opendev.org/c/openstack/governance/+/984545 - Add devstack-plugin-lustre to QA | https://review.opendev.org/c/openstack/governance/+/987314 === Upcoming Events === - 2026-05-12: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-05-16: OpenInfra Day Nigeria (Jalingo): https://www.meetup.com/openstack-nigeria-user-group/events/313525373/ - 2026-05-18: Open Source Summit | Embedded Linux Conference, North America : https://events.linuxfoundation.org/open-source-summit-north-america/ - 2026-05-21: OpenInfra Forum (Stockholm): https://www.meetup.com/openinfra-user-group-sweden/events/313615139/ - 2026-06-05: OpenInfra Colombia User Group (Bogotá): https://www.meetup.com/colombia-openinfra-user-group/events/313396409/ - 2026-06-16: Open Source Summit India: https://events.linuxfoundation.org/open-source-summit-india/ - 2026-06-18: KubeCon + CloudNativeCon India: https://events.linuxfoundation.org/kubecon-cloudnativecon-india/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.2 "Hibiscus" Release Schedule: https://releases.openstack.org/hibiscus/schedule.html [2] Removal of enforce_scope impact: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] RBAC global auditor (reader): https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] TC Meeting IRC Log, May 05 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-05-05-17.00.html [5] Venus retirement cleanup patches: https://review.opendev.org/q/topic:%22retire-venus%22 [6] Add PQC Migration popup team: https://review.opendev.org/c/openstack/governance/+/982062 [7] Add agentic-workflows to TaCT SIG: https://review.opendev.org/c/openstack/governance/+/984958 [8] TC Meeting Agenda, May 12 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[kolla] propose a new migration utility for the Kolla-Ansible
by Eduardo Morais 11 May '26

11 May '26

Hi everyone, For the past few months, I’ve been working on a migration tool for Kolla Ansible designed to transition deployments from OVS to OVN. I’m interested in contributing this tool to the Kolla project and would love to hear your thoughts on this proposal. Looking forward to your feedback! this is the tool: https://github.com/ufcg-lsd/migration-tool-openstack-kolla/tree/migration-t…

2 2

[ops][ironic] TLS controls? tls 1.3?
by Julia Kreger 11 May '26

11 May '26

Greetings folks, Recently I have been working on a series of patches to add TLS version and cipher controls to Ironic to enable operators to tighten the security posture by aligning service operating state with their policy and controls. In this series, I started to assert a default of TLS 1.2 with a configuration knob to alternatively select TLS 1.3, or None. Granted, operating and deployment models differ. One operator may be using ironic's API service, while another may be doing TLS termination in a separate web server which is entirely outside of Ironic's control. But when it comes to backend service interaction, for example when accessing HTTPS servers for artifacts, or baseboard management controllers, it just seems like a good idea to assert a default version of TLS for service interactions. Which has me wondering if the default should be TLS 1.3? Specifically, I'm wondering if there is any objection to something along the lines of: * The Ironic API service defaults to TLS 1.3 when configured to terminate TLS. * The JSON-RPC endpoint for API->Conductor communication would do the same if in use. * The Ironic-Python-Agent service endpoint and communications defaulting to TLS 1.3 * The oci:// and https:// artifact URL access paths would similarly want to default their connections to TLS 1.3. * Redfish BMC access would have *NO* default, but would have overall control which could be "opt-in". This is largely because vendors mostly only support TLS 1.2 and even TLS 1.1 with older , but likely still in production. This would be on the "back-end" in an environment with substantial mitigating controls when an environment is properly configured with restricted access to baseboard management controllers. Cipher selection would default to the OS or distribution default, but could be overridden. What I would consider out of scope is outbound connections to other OpenStack services. This is because operators would be in control of the configuration parameters for whatever front-end they are terminating SSL on, and on a client side it would need to be a capability added to keystoneauth. Thoughts? Concerns? -Julia

1 0

[OSSA-2026-012] Ironic: Remote Code Execution when Anaconda driver enabled
by Jay Faulkner 11 May '26

11 May '26

===================================================================================== OSSA-2026-012: Remote Code Execution in Ironic conductor when Anaconda driver enabled ===================================================================================== :Date: May 11, 2026 :CVE: CVE-2026-44916 Affects ~~~~~~~ - Ironic: >=17.0.0 <26.1.7, >=27.0.0 <29.0.6, >=30.0.0 <32.0.2, >=33.0.0 <35.0.2 Description ~~~~~~~~~~~ Dmitry Tantsur (Red Hat) and Tuomo Tanskanen (Ericsson Software Technology) from the Metal3.io Security Team reported a vulnerability in Ironic's anaconda deploy interface. Users who can set ``node.instance_info['ks_template']`` can achieve remove code execution on the ironic-conductor process, as the template is rendered without sandboxing. In the default configuration, Ironic is not vulnerable to this issue. However, operators who have enabled the anaconda deploy interface by adding it to ``[conductor]/enabled_deploy_interfaces`` and have untrusted users with access to modify ``node.instance_info`` are at risk. Patches ~~~~~~~ - https://review.opendev.org/c/openstack/ironic/+/987778 (2023.1/antelope (unmaintained)) - https://review.opendev.org/c/openstack/ironic/+/987777 (2024.1/caracal (unmaintained)) - https://review.opendev.org/c/openstack/ironic/+/987776 (2025.1/epoxy) - https://review.opendev.org/c/openstack/ironic/+/987775 (2025.2/flamingo) - https://review.opendev.org/c/openstack/ironic/+/987774 (2026.1/gazpacho) - https://review.opendev.org/c/openstack/ironic/+/987922 (Bugfix/31.0) - https://review.opendev.org/c/openstack/ironic/+/987921 (Bugfix/33.0) - https://review.opendev.org/c/openstack/ironic/+/987920 (Bugfix/34.0) Credits ~~~~~~~ - Dmitry Tantsur from Red Hat - Tuomo Tanskanen from Ericsson Software Technology References ~~~~~~~~~~ - https://bugs.launchpad.net/ironic/+bug/2148307 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-44916 Notes ~~~~~ - Releases 2024.1 (caracal) and 2023.1 (antelope) are unmaintained. Patches are provided as a courtesy. Releases 2023.2 (bobcat) and 2024.2 (dalmation) are end of life and have not had patches provided. See https://releases.openstack.org for more information on supported releases. - Ironic bugfix branch patches will be available in git for interested operators. We will not perform an additional release from these branches.

1 0

seeking advice on operating heterogenous storage types
by Jiatong Shen 11 May '26

11 May '26

Hi, I am seeking advice to maintain an openstack cluster with heterogeneous storage types. The problem is the compute nodes in one availability zone cannot use all available storage types. For example, some compute nodes do not have FC connectivity and thus cannot use FC SAN storage; Some compute nodes do not have 10G network and thus cannot use Ceph. Such setup makes operations like resize/evacuate easy to fail and hard to fix. Sincerely appreciate any advice. Thank you. -- Best Regards, Jiatong Shen

2 2

Proposal: Add Dell Unity storage backend support
by aydin tabatabaei 11 May '26

11 May '26

Hi team, I'd like to propose adding support for Dell Unity as a storage backend in kolla-ansible. Dell Unity is a widely used mid-range unified storage platform, and adding native support would allow kolla-ansible users to integrate it as a Cinder backend without manual workarounds. Before I start working on the implementation, I wanted to: 1. Check if there is already any ongoing or planned work in this area 2. Get early feedback on whether this is a direction the team would accept 3. Understand any architectural or contribution guidelines I should follow I plan to follow the standard contribution process (blueprint/spec if needed, unit tests, CI, documentation), but wanted to align with the team first to avoid duplicating effort. Happy to discuss scope, approach, or anything else before I begin. Please let me know your thoughts! Thanks, Aydin Tabatabaei

3 2

[nova] libvirt driver doesn't export smbios data for AARCH64
by tamng＠amperecomputing.com 11 May '26

11 May '26

Hi all, Recently, I setup a Openstack cluster on AARCH64 host (Ampere Platform) using Kolla-Ansible. And I run to the issue where the `cloud-init` doesn't start. After debuging I see the Guest VM SMBIOS data doesn't show the "OpenStack" string that `cloud-init` is expecting. Instead of the "OpenStack" string, my VM show the default QEMU/KVM info. By checking the libvirt's driver.py code, only x86 arch supports export SMBIOS data to Guest VM: https://opendev.org/openstack/nova/src/commit/ff4ea2dea9fa5d14662d11f7399be… I would like to submit the change to support export SMBIOS data for AARCH64 VM, but I wonder if there were some other efforts to make this change. Are there anything I need to look out when doing it? Is there any test I need to add for that code? Best regards, Tam Nguyen

2 2

Is there a safer way to handle untrusted disk images than qemu-img?
by Michael Still 09 May '26

09 May '26

For a while now I've been wondering if there's a safer way to handle untrusted disk images in various clouds. They're a frequent cause of security vulnerability announcements, largely because qemu is a fairly complicated code base where the block device handling is entangled into the larger product, qemu also implements a variety of features clouds don't even want, and poorly intentioned people can spend as much time as they want crafting custom images to find interesting edge conditions in the implementation. I am not convinced that the current strategy of closing gaps as they're found is really paying off. Recent examples of such `qemu-img` related vulnerabilities include: * CVE-2026-24708 (OSSA-2026-002) * CVE-2024-44082 (OSSA-2024-003) * CVE-2024-4467 (OSSA-2024-002) * CVE-2024-32498 (OSSA-2024-001) * CVE-2022-47951 (OSSA-2023-002) I toyed with the idea of a "stripped down" `qemu-img` which could simply not have the features which cause these vulnerabilities, but the complexity of the qemu codebase makes this approach painful, while also not presenting any of the other opportunities of a greenfields approach like memory safety and a tight sandbox. So what might a safer approach look like? My answer is to try and offload the processing of untrusted data to the virtual machine implementation in silicon -- it has strong separation guarantees and it can be orchestrated so that there is simply no access to anything not required for the strict processing of the image. So for example no access to a file system, a network, and so forth. Specifically, what if processing this untrusted and potentially malicious data was done as a KVM guest with a custom virtual machine manager (VMM)? So I wrote it, and by "I wrote it" I mean Claude Code mostly wrote it. Instar is a from scratch rethink of how to handle untrusted image data as well as an opportunity for me to become more familiar with code generation LLMs. All data processing happens in a custom KVM guest which does not run an operating system or have any access to system resources apart from those provided to it by the custom VMM which orchestrates it. The best way to think of this guest is as an embedded system running on a virtual CPU. This is similar in approach to how AWS Nitro Enclaves work in terms of prior art, whilst also being the opposite in intent: Nitro protects sensitive data *from* the cloud; instar protects the cloud *from* malicious data. To be clear, `instar info` doesn't detect or block malicious images -- it processes them safely and reports what it finds. The security comes from containment, not detection. It is then up to the caller to decide how to handle what is reported. Instar currently requires Linux with KVM support on x86-64. Early benchmarks suggest performance overhead from the KVM sandbox is modest -- in the noise for metadata operations like `info`. Images are provided to this guest as block devices using the virtio-block protocol, but it should be noted that while the guest and the VMM are using that protocol, the Linux kernel is not involved. Instar is implemented in rust because bare metal golang turned out to be a bit hard, and because the existing rust VMM crates are actually quite good and used by projects like Firecracker already. You can read more about the technology choices and concepts behind instar in painful detail at https://shakenfist.com/components/instar/technology-primer/ The primary use case I'm targeting is validating untrusted images at upload time (e.g., in Glance), though the same approach could apply anywhere qemu-img is invoked on user-supplied data. The current goal of Instar is to be command line compatible with qemu-img (especially `qemu-img info` and `qemu-img convert`), but I also wonder about opportunities to get out of the game of parsing command output. Whilst Instar can certainly emit JSON formatted output, there are other options as well like running it as a persistent daemon which services requests it receives over a unix domain socket. I've played that game with other code recently and find protobufs to be a reasonable protocol for such things. I don't know how OpenStack feels about protobufs however. By "command line compatible", I mean that my current goal is to provide a version of `instar info` and `instar convert` that is byte for byte identical to the output of the same `qemu-img info` or `qemu-img convert` command. This has some interesting edge cases in as much as `qemu-img` has changed its output format at least once since 2020. Additionally, I suspect I've found at least one `qemu-img` bug in this process. Instar resolves these issues by having a test suite of sample images, recording the `qemu-img` output for those images, and then generating a database of the different output formats. When you run `instar info` on your machine, instar attempts to detect the version of `qemu-img` you have installed, and will match its output format. The interesting little edge cases I've found along the way are documented at https://shakenfist.com/components/instar/quirks/, and the output formats the `qemu-img info` produces are documented at https://shakenfist.com/components/instar/output-formats/. At the moment I'd describe Instar as a "vigorous prototype". It implements `qemu-img info` and most of `qemu-img convert`, but does not yet know how to resize, rebase, snapshot, and so forth. I'd be interested in whether other people think this is an interesting idea or not, although honestly it was just kind of fun to build over the summer holidays. I'd particularly welcome feedback on whether this approach would be useful for your deployment, examples of images that produce unexpected results, and thoughts on the daemon / protobuf interface idea. Instar is licensed under Apache 2.0. The code and extensive notes are at https://github.com/shakenfist/instar/. Bug reports, examples of images which didn't work as expected, and pull requests should all go there please. Michael

1 0