November 2025 - openstack-discuss

[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Jean-Philippe Jung 21 Mar '26

21 Mar '26

Hi, I am the OpenStack Security Product Manager at Red Hat. I also support Post Quantum Cryptography in OpenStack and k8s (well, OpenShift for us), and I cover some areas of confidential computing. I see one existential risk to OpenStack in the near future: support for post-quantum cryptography (PQC) [0] Based on my latest discussion with industry experts, I expect that around 2029 (likely) or 2030 (at best), there would be powerful enough Q-Computers to break traditional cryptography. Meaning we have to prepare OpenStack to support post-quantum crypto (ML-KEM urgently, ML-DSA as soon as possible) in the upstream code. As we also need to provide time for operators/customers to implement the "fixed" code, we are in early 2028 territory to achieve sufficient PQC coverage in OpenStack upstream. This would give OpenStack users time to implement this code. Time is running out; we’re already almost in 2026! A point to keep in mind is that the initial PQC algorithms might fall short and be replaced in the future. Thus, this PQC support exercise should also be a “cryptographic agility” exercise: we should have a few libraries we know how to call, and if a new crypto algorithm comes out, it should be easy to enable it in the code. I used AI engines to have a look at the OpenStack upstream code (not all projects, but a chunk of the most commonly used), and I came back with 17 different cryptographic modules, 7 of which received no commits in over 2 years. It might be directly in the code or in pulled dependencies. The first step to solving a problem is recognizing we have one. We have a problem. I am seeking help from the TC to raise the urgency of this work across all OpenStack projects and to help me lead an effort to reduce the number of cryptographic modules used in OpenStack (my personal opinion is that there should be no more than five). Doing this may involve work in each OpenStack Project team; and I can help organize this effort. I'm seeking the following from the TC and/or project teams: Portions of this work will be isolated to specific repositories managed by a project team, while others will involve "cross-project" synchronization. What vehicles can we use to have a "call-to-action" for project teams to get someone to look into their specific projects? How can we go about community wide collaboration? I've created a document [1] that I assembled from AI analysis of part of the OpenStack code. It gives an overall view of the problem we face. Looking forward to hearing from you and collaborating upstream to improve OpenStack. Regards, Jean-Philippe (JP) Jung jjung(a)redhat.com irc: jjung [0] Quantum what? Quantum computers will break current encryption algorithms like RSA and elliptic curve cryptography using Shor's algorithm, exposing all data encrypted today. Adversaries are already harvesting encrypted data to decrypt later once quantum computers mature. OpenStack powers critical cloud infrastructure globally. Deploying post-quantum cryptography (PQC) upstream is essential because downstream distributions and deployments inherit these security foundations. Without upstream PQC integration, the entire OpenStack ecosystem remains vulnerable, putting sensitive workloads, government systems, and enterprise data at risk. The migration takes years, so implementing PQC now in the codebase is operationally necessary, not optional. [1] https://wiki.openstack.org/wiki/Post_quantum_openstack

9 16

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

16 Feb '26

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

3 3

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

11 Feb '26

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

2 2

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

28 Jan '26

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

3 6

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

26 Jan '26

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

2 7

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

16 Dec '25

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

2 9

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

09 Dec '25

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

2 16

[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

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