- openstack-discuss - lists.openstack.org

[nova][glance] Server rescue falls back to default image
by Francesco Di Nucci 29 Oct '25

29 Oct '25

Hi all, I am on OpenStack Caracal, trying to rescue a VM that's not booting: * I previously created a SystemRescueCD rescue image (with openstack image create --file ./systemrescue-12.02-amd64.iso --disk-format raw --container-format bare --property hw_rescue_bus=virtio --property hw_rescue_device=disk systemrescuecd_1202) - it works on VMs that still have their base images in Glance * tried to rescue the VM (with openstack server rescue --image systemrescuecd_1202 my-vm-id-here) * but the process fails as it tries to also use the base image used to create that VM, instead of the rescue image only (Instance my-vm-id-here cannot be rescued: Driver Error: Image b78cf456-b395-434f-bf50-a1f2f3684a37 could not be found. ; where b78cf456-b395-434f-bf50-a1f2f3684a37 was a Ubuntu cloud image used to create that VM, since deleted as it's an EOL version) Is it supposed to also try to use the base image or should the --image bypass it? In case, what could I do? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

3 2

[kolla-ansible] Rabbitmq queue creation issues in "fresh" 2025.1 deploy
by Jonathan Proulx 28 Oct '25

28 Oct '25

Hi All, I'm putting "fresh" in quotes becuase I expect the issue is some home my deploy isn't as fresh as I belive it to be. I did have and older test environment which was serveral steps behind (and not quite workign for other reasons). The presenting issues is this error (and other similar ones for other services): 2025-10-24 11:44:07.840 1076 WARNING oslo.messaging._drivers.impl_rabbit [None req-4eff1f78-c16a-4bc9-b0da-9ce0a80b66ba - - - - - -] [83941886-4e9c-4d0c-b3b0-53c107f018e9] Queue conductor could not be declared probably because of conflicting configurations: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'nova' in vhost '/': received 'true' but current is 'false': amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'nova' in vhost '/': received 'true' but current is 'false' 2025-10-24 11:44:07.841 1076 INFO oslo.messaging._drivers.impl_rabbit [None req-4eff1f78-c16a-4bc9-b0da-9ce0a80b66ba - - - - - -] [83941886-4e9c-4d0c-b3b0-53c107f018e9] Retrying to declare the exchange (nova) as non durable I'm puzzled since the services are deploying to recently reinstalled nodes (I'm sure that part is fresh) how the queues can be created with flags the services don't expect. my shell history tells me I'm using these versions (in a venev): pip3 install --upgrade git+https://opendev.org/openstack/kolla-ansible@stable/2025.1 pip3 install --upgrade git+https://opendev.org/openstack/kolla@stable/2025.1 pip3 install --upgrade 'ansible-core>=2.17,<2.18.99' The only bits I know are left over and "upgraded" from previous attempts are my configs in /etc/kolla. My deploy host wasn't reinstalled but I did delete and recreate the venv. Using Ubuntu 24.04 as the base OS Where do I go from here to find my wrong turn? Thanks, -Jon -- Jonathan "Some Day I'll Upgrade From Mitaka" Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 4

Re: [tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Jean-Philippe Jung 28 Oct '25

28 Oct '25

Hi, Thanks for the comments, and let me try to group some & reply ahead of the PTG session. 1- Quantum computers are no threat, they are underpowered, so what’s the risk & why should we do anything now? * The issue is time. The day a quantum computer is powerful enough to break traditional cryptography (known as Q-day), it is too late. OpenStack lays naked and vulnerable. * We can argue about dates, and my current opinion is that to be on the safe side, any software product should implement PQC cryptography by 2029. * We have a large code base, and we need to give time to the community to review & adjust it then to openstack operators to implement quantum-safe cryptography. * There is no snake oil/panic-driven agenda here, either we protect access to OpenStack infrastructure & between services, preferably by 2028. Or we don’t. We have time, but we should start work now. 2- It’s a problem for Operating System vendors, we just consume their cryptography. * I wish it were true. But the initial analysis I made demonstrates we have libraries that do cryptographic operations, and maybe these libraries end up properly calling an OS cryptographic module. Maybe not. I know of paramiko, that does not call any OS layer, but its own copy of OpenSSL code. We cannot assume OpenStack has nothing to do until we analyse our cryptographic usage. * I totally support the idea of using OS cryptography as much as possible, because we offload the maintenance problem to OS vendors. * Then because new fancy cryptographic algorithms have been finalized (key encapsulation, ML-KEM), or near finalized (digital signature, ML-DSA) does not indeed mean they are available in all the protocols that uses them (IPsec, kerberos, dnssec…) in operating systems. 3- Some of the libraries listed might no longer be in used. * The code should be removed from OpenStack. We have customers doing Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST): these will flag those unsafe modules. * Other side of that point: some of these libraries are still used. Do they rely on an operating system cryptography, or do they pull their own cryptographic call? Are they maintained? Should we reduce the amount of cryptographic modules in OpenStack? 4- There is no plan proposed, what’s next? * Initial email was to express my concern about supporting PQC in OpenStack, understanding if my concern was shared, and raise awareness on this topic right ahead of the PTG. * The first step to solve a problem is to know there is a problem, I’d start with a per project effort starting with a simple question for projects: "Does your project do anything in relation to keys, encryption, or interaction of any encrypted data either at rest or while in transit?" * Next would be to use those results to plan for protecting OpenStack against the store-now, decrypt-later attacks, meaning protecting key exchanges relaying on ML-KEM (well hybrid X25519MLKEM768 to start with), ensuring symmetric keys are long enough (256 bits minimum), then deal later with digital signatures code (if any). 5- The goal is premature * I consider this a community goal because all OpenStack components must achieve support pretty much in the same time frame. I am not saying it should take precedence over any other critical work (e.g., eventlet removal), I think now is the time to scope the work and plan to meet the 2027/2028 deadline. * OpenStack customers planning to run it well into the 2030s are asking about the plans for PQC support. And new customers considering OpenStack are asking about PQC support plans. Either we have an answer, a roadmap, or OpenStack will not be part of the discussion, at some point (ask me how I know :-). Regards, JP

1 0

pip 25.3 removes support for legacy editable installs
by Stephen Finucane 28 Oct '25

28 Oct '25

o/ pip 25.3 was released on Friday (who does Friday releases?!) and had removed support for the legacy `setup.py develop` editable install method in setuptools [1]. Now, thankfully most services seem to have listened to me [2][3] and the shouty warnings from setuptools/pip and migrated away from 'wsgi_scripts'. However, there is a good chance that older stable branches are missing these migration patches and consequently now broken. For example, it seems keystone is missing these changes on stable/2024.2, and attempts to deploy that branch currently fail with: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Internal Server Error (HTTP 500) which, upon further inspection, will turn out to be a missing wsgi script: devstack(a)keystone.service[40466]: failed to open python file /opt/stack/data/venv/bin/keystone-wsgi-public We have already seen this pop up on the cluster-api-provider-openstack (CAPO) project [4], which is using the old stable/2024.2 (Dalmatian) release. I have proposed fixes to stable/2025.1 [5] and stable/2024.2 [6] to constrain pip on those older branches. This should fix the issue for everyone, provided you're not using a devstack plugin that re-updates pip. Individual services may also wish to backport the patches that added '$service.wsgi' modules if possible, to fix this for non-devstack use cases, but this won't be possible in all cases. Hope this helps, Stephen [1] https://pip.pypa.io/en/stable/news/#v25-3 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/28… [5] https://review.opendev.org/c/openstack/devstack/+/965092 [6] https://review.opendev.org/c/openstack/devstack/+/965093

2 1

[keystone][ptg] Keystone PTG schedule is available (Tue and Wed)
by Artem Goncharov 28 Oct '25

28 Oct '25

Hey guys, The Keystone team is meeting today and tomorrow for the PTG. Today's focus are the federation topics, passkeys, service accounts and discussion of feature deprecation that depend on the software abandoned upstream (i.e. saml2). Tomorrow we are going to focus more on the cryptography used in Keystone, Horizon cross-session and certain cli aspects. You are very welcome to join us discussing the future of Keystone. TECHs of today put big challenges in front of us and we need to do rework no matter how hard and painful it is. https://etherpad.opendev.org/p/oct2025-ptg-keystone Regards and see you in already a bit Artem

1 0

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2026
by Piotr Kliczewski 28 Oct '25

28 Oct '25

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2026, to be hosted on 31st of January. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by 5th December 2025. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM, libvirt, shared storage, virtualized networking, cloud security, clustering and high availability, interfacing with multiple hypervisors, hyperconverged deployments and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 5th December 2025 Acceptance notifications: 10th December 2025 Final schedule announcement: 15th of December 2025 Devroom: 31st of January Submit Your Proposal During submission [1] please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, Piotr Kliczewski and Tal Nisan In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM[2], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] https://fosdem.org/2026/practical/conduct/

1 0

[swift][ptg] Ops Feedback Session - 29th October at 1300 UTC
by Matthew Oliver 28 Oct '25

28 Oct '25

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in the gazpacho swift meetpad room ( https://meetpad.opendev.org/swift-ptg-gazpacho) on Wednesday at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad ( https://etherpad.opendev.org/p/swift-gazpacho-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0

[tacker][ptg] 2025.10 vPTG Planning
by Yasufumi Ogawa 27 Oct '25

27 Oct '25

Hi tacker team, As we discussed in the previous meeting, we'll have two days sessions for the vPTG. I've fixed time slots for our vPTG session[1] and setup the etherpad[2]. Please add your items on the etherpad if you have any proposal. - 29th Oct. 8am-10am UTC (5pm-7pm JST/KST) - 31th Oct. 8am-10am UTC (5pm-7pm JST/KST) [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/oct2025-ptg-tacker Regards, Yasufumi

1 0

[kolla][kolla-ansible][kayobe] Bifrost usage poll
by William Szumski 27 Oct '25

27 Oct '25

Hi all, I was just trying to get an idea for the number of operators relying on the Bifrost support in Kolla-Ansible as it was recently deprecated in Kolla[1]. We are planning the next steps for its replacement, and are not sure if it is is only Kayobe users that would be affected. If you you are using Bifrost and not using Kayobe, I would appreciate if you could reply to this message. We will also be discussing Bifrost as the first topic in the Kayobe/Kolla PTG session on Wednesday 19th November at 13:00 UTC and would encourage you to come along and discuss its future. Although, nominally it is the Kayobe session, we've made the first topic on the agenda so that you easily drop out if you aren't interested in the rest of the discussion. [1] https://review.opendev.org/c/openstack/kolla-ansible/+/945501 Thanks, Will

1 1

[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Jean-Philippe Jung 27 Oct '25

27 Oct '25

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

7 12