June 2026 - openstack-discuss - lists.openstack.org

[nova] Proposals for changes to nova-core
by Stephen Finucane 03 Sep '26

03 Sep '26

[BCC current nova core group, not all of whom were present today] o/ During today's nova PTG sessions, we discussed Sean Mooney's recent proposal [1] to introduce new nova-approver and nova-reviewer groups, akin to the model used by Ironic in recent releases. The conversation was initially expected to focus on the onboarding of new nova cores, but ended up turning into a discussion on how best to use the experience of SMEs from other OpenStack services with integration in nova to make progress on their features in a timely manner. This was heavily inspired by discussions between the Ironic and Nova teams earlier this week. During the discussion, it became clear that there were a variety of potential options on the table and many of the Nova cores present had different and often competing preferences. In order to break the deadlock, we agreed to codify four proposals into changes to the Nova contributor docs submitted to Gerrit. This is now done, and the four proposals can be found here: * https://review.opendev.org/c/openstack/nova/+/986141 (option 1) * https://review.opendev.org/c/openstack/nova/+/986142 (option 2) * https://review.opendev.org/c/openstack/nova/+/986143 (option 3) * https://review.opendev.org/c/openstack/nova/+/986144 (option 4) I have attempted to capture the intent of the proposals in the changes themselves, but for the avoidance of confusion I will repeat the guidance here, in a bullet point format: * These patches *should not* be merged yet. Nova cores are asked to +1 the options that they are *okay with* and -1 those that are *not okay with*. A +0 vote is considered neutral and is not included. This is known as "Approval Voting". * Small issues with wording and typos can be noted, but should not affect the overall vote: we can address these issues before we merge the patch. * Additionally, none of these proposals should imply a change in our general policy for onboarding new cores. * We will proceed with the most popular proposal for the remainder of the H cycle and evaluate the outcome during the next PTG (expected in October 2026). At that point, we will decide whether to persist with the proposal and merge this patch, or make changes. The ask is for all existing nova cores to weigh in on the proposals and explicitly submit a -1, 0, or +1 vote on each patch. I will stress again that we are not looking for a solution that is everyone's favoured solution as such a solution does not appear to exist. Rather, we are looking for a solution that is *acceptable* to the largest percentage of existing nova cores. I propose that we give it a week for people to assess the options and provide their opinions. At that point we'll proceed with the chosen proposal for the duration of the H cycle. Cheers, Stephen [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 2

[openstack][nova]qemu system wont release memory
by Nguyễn Hữu Khôi 25 Aug '26

25 Aug '26

Hello. I have an OpenStack instance that was using 14GB out of 16GB of memory. Later, when it was using only 4GB, I checked the QEMU process on the compute node, and it was still consuming 14GB, this means memory isn't released when usage decreases. Do we have solutions for this? I use Ubuntu 24.04 instances. Nguyen Huu Khoi

2 13

kolla-ansible support for Ubuntu 2024.04/ARM64 ?
by dariusz.bursztynowski＠pw.edu.pl 18 Aug '26

18 Aug '26

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (e.g., to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

2 1

[OSSA-2026-007] OpenStack Keystone: LDAP identity backend does not convert enabled attribute to boolean (CVE PENDING)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

================================================================================== OSSA-2026-007: LDAP identity backend does not convert enabled attribute to boolean ================================================================================== :Date: April 14, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Keystone: >=8.0.0 <25.0.1, >=26.0.0 <26.1.1, >=27.0.0 <27.0.1, >=28.0.0 <28.0.1 Description ~~~~~~~~~~~ Benedikt Trefzer and Andrew Bogott independently reported a vulnerability in the Keystone LDAP identity backend. When the user_enabled_invert configuration option was False (the default), Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate. Deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected. Patches ~~~~~~~ -https://review.opendev.org/982409 (2024.2/dalmatian) -https://review.opendev.org/982408 (2025.1/epoxy) -https://review.opendev.org/982407 (2025.2/flamingo) -https://review.opendev.org/958205 (2026.1/gazpacho) Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-pending) - Andrew Bogott from Wikimedia Foundation (CVE-2026-pending) - Grzegorz Grasza from Red Hat (CVE-2026-pending) References ~~~~~~~~~~ -https://launchpad.net/bugs/2121152 -https://launchpad.net/bugs/2141713 Notes ~~~~~ - To work around this vulnerability, set user_enabled_invert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use user_enabled_emulation with group-based enabled status. - A CVE request was filed with MITRE on 2026-04-10. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release. -- Goutham Pacha Ravi (gouthamr) OpenStack Vulnerability Management Team

1 1

[policy] Removing the enforce_scope config option
by Ghanshyam Maan 17 Jul '26

17 Jul '26

Hello everyone, As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag. What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered. Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure. 2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3]. How to test your project: I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475) oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479 Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies. - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(statu… I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope. [1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.en… [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a… -gmaan

3 13

[riscv-sig] Proposal for a New SIG: Accelerating RISC-V Adoption in OpenInfra
by li.xiang2＠zte.com.cn 14 Jul '26

14 Jul '26

Dear OpenInfra Leadership and Community Members, I am Xiang Li, representing ZTE Corporation within the OpenInfra Foundation. I am writing to you today to propose a strategic initiative that I believe will be a defining milestone for our ecosystem: the establishment of a RISC-V Special Interest Group (SIG). As the industry pivots toward RISC-V, particularly with the imminent commercial rollout of high-end RVA23 servers, we see a unique opportunity to align OpenInfra projects—with a primary focus on OpenStack—with this transformative architecture. By formally integrating RISC-V compatibility, we can ensure that our cloud infrastructure remains at the forefront of open-source innovation. To drive this mission forward, we propose the formation of a RISC-V SIG dedicated to the following objectives: Collaborative Strategy: We aim to unite vendors and contributors passionate about RISC-V to define the requirements and proposals necessary to optimize cloud infrastructure technologies for this architecture. Infrastructure Excellence: Building a reliable foundation is crucial. ZTE is eager to take the lead by donating physical RISC-V server hardware and providing dedicated engineering resources. Our goal is to establish a robust CI/CD pipeline, ensuring seamless compilation and automated testing for the community. Knowledge Sharing & Growth: Through technical presentations at meetups and summits, we hope to champion RISC-V-based cloud infrastructure, fostering community growth and attracting new contributors and partners to the ecosystem. We are deeply committed to being a reliable, proactive partner in this journey and believe that RISC-V support will significantly strengthen the future of cloud infrastructure. We would be honored to have your support and guidance as we launch this initiative. Thank you for your time, your leadership, and your thoughtful consideration of this proposal. We look forward to your valuable feedback. Our SIG whiteboard: https://etherpad.opendev.org/p/RISC-V-SIG Sincerely, Xiang Li ZTE Corporation

3 3

[security][all] OpenStack Security Documentation crisis; prioritizing security work
by Jay Faulkner 06 Jul '26

06 Jul '26

Hey all, Almost two and a half years ago, I sent an email[0] to the OpenStack mailing list about a giant problem -- so giant I didn't know how we would solve it. Now, we've got multiple OpenStack services running without eventlet. Our community understood the importance of that moment and acted -- I'm hoping to see similar action here for a similarly giant issue. Security is a hot topic in the industry, and too, in OpenStack. We've had pushes for Post-Quantum Cryptography. We've published more OSSAs this year than any other year in the last decade. I'm a little bit concerned that we're missing the lower-hanging fruit, and not giving our operators the tools they need to understand and manage risk in their environments. We've got a handful of examples that have come up recently that are good to think about in this context: https://bugs.launchpad.net/ossa/+bug/2157914 https://bugs.launchpad.net/ossa/+bug/2156952 https://bugs.launchpad.net/ossa/+bug/2156944 https://bugs.launchpad.net/ossa/+bug/2156937 https://bugs.launchpad.net/ossa/+bug/2156808 https://bugs.launchpad.net/ossa/+bug/2156807 These bugs, in summary, indicate that several cinder and manila drivers may not be configured securely by default, and in some cases, may be impossible to secure altogether. These issues are not strictly security vulnerabilities -- and in many cases don't even violate a strictly-applied "secure by default" constraint (cinder or manila do not enable any of these backends by default). Instead, they represent a minefield that our users have to navigate anytime they want to use storage. The interesting thing is also that they probably wouldn't have even been considered security risks at all in a major way in 2015 -- as many professional cloud admins then would've used a completely separate storage network to protect their data and credentials. In a 2026 world, I think it falls on OpenStack to help document the risks here. I'm not picking on Cinder and Manila specifically, they just were audited recently and made a good example here. There are others. For instance, in https://bugs.launchpad.net/kolla-ansible/+bug/2158004 there's a comment that makes it really clear we're not talking to each other about security requirements for the services themselves. Ironic developers removed the need to ever run our container as privileged, but that never got documented (honestly, not sure WHERE we would document it where folks would see it). Similarly, Ironic has drivers with security downsides that may not be as well documented as I like. We are all intensely busy. In no way am I suggesting that we should take these bugs as a punch list to go fix all the issues -- I'm not sure we have time, hell I'm not even sure they're all in use. However, we need to make sure to have a clear, concise place where we disclose the limitations of certain drivers or use cases so that operators can make informed decisions about risk. I don't have specific wording yet, but I'd suggest the project make a commitment -- I can make it a TC resolution or goal if there is consensus -- to do the following: - Audit our default configurations. Ensure that any insecure defaults are changed to their secure equivalent. Options which, when changed, reduce the security stance of the project should have that security risk documented inline. - Agree upon a basic, terse format[1] we can use across all projects to disclose summary security information about drivers and have projects with driver models implement this. (replace "driver" with "backend", "plugin" or related concept as necessary) - Consider releasing an OSSN with the findings of these audits to trigger downstream operators to re-evaluate their configuration. I strongly suspect there may be examples of projects doing this well I'm not very familiar with -- I'd love to hear about those and see the docs. I did not perform a full audit of all projects and mostly am communicating things unearthed by others to try and draw attention to them. In a world where we have LLMs pointed at OpenStack, trying to find the right combination of configurations to find a vulnerability -- or pushes to secure our keys against quantum attack vectors -- it only makes sense to me that we take a step back and try to ensure our default configurations and documentation lay out the risks and trade-offs clearly. OpenStack is over 15 years old; we know by now it's impossible to keep every corner of the project with pristine, latest and greatest security methods. Every now and then though, we need to look back and raise the floor -- I think that time is now. Thanks, Jay Faulkner Security SIG Co-Chair & Ironic Security Liaison 0: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… 1: For instance, https://docs.openstack.org/cinder/latest/admin/security.html#network-traffic indicates to check the driver pages, and the driver documentation pages (while thorough!) do not have any standard way of communicating their security stance. Aggregating this information would help both new OpenStack users and hardware purchasing decisions by existing OpenStack users.

4 4

Security patch updates regarding OpenStack on Debian
by Thomas Goirand 02 Jul '26

02 Jul '26

Hi, tl;dr: I'm up-to-date, please do upgrade your OpenStack cluster Just wanted to let everyone know that in Debian, for Keystone, I managed to backport up to Victoria, plus Train, since this was a major flow. I wasn't able to go up to Rocky as I wish I would (as this is the version in Debian 10, aka Buster). Bullseye already has the patch, Bookworm and Trixie soon will receive it. The unofficial backport repositories from osbpo.debian.net have all of the above, plus intermediary releases (as usual). In general, Debian is up-to-date regarding all recently disclosed CVEs (including, but not limited to: Cyborg, Neutron, Swift...) even though some announces are pending. Note that for Ironic, I am giving up maintaining anything before Bullseye / zed, as the number of CVE are too big, and that'd be too much work. FYI, working on these security issues was my full-time work last week. Cheers, Thomas Goirand (zigo)

3 6

[kolla][horizon][2023.1] unable to replace XStatic-jQuery dependency in Horizon
by Rob Jefferson 02 Jul '26

02 Jul '26

Folks, I am trying to build Kolla images for 2023.1, for patching vulnerabilities. I've gotten everything to build, except for Horizon. I am stuck on changing the version of one of the dependencies, XStatic-jQuery, and don't know how to resolve it. Basically, I want to replace a Python package version in Horizon with a different one; unlike other packages, this one (XStatic-jQuery) requires versions to be in a range, so upper_constraints_version_change doesn't work as expected. Below, I tried a variety of approaches, none of which yielded a built container. Any help on resolving this would be quite appreciated, since I have been trying to fix this for several days. Thanks, Rob ----- When I first tried to build the Horizon container image, I received an error while trying to build a wheel for XStatic-Angular-FileUpload, that it couldn't build a wheel because `pkg_resources` wasn't there. setuptools removed that in version 82.0, so I downgraded to 81.0 using && {{ macros.install_pip(['pip', 'wheel', 'setuptools==81.*']) }} \ (after line 50 in the Horizon Dockerfile: https://github.com/openstack/kolla/blob/2023.1-eol/docker/horizon/Dockerfil… ) The problem continued to occur. I then decided to bump up the versions of the XStatic* packages one at a time, and those built until I hit XStatic-jQuery. That wouldn't build, and when I tried to bump the version to 2.2.4.1 via & {{ macros.upper_constraints_version_change("XStatic-jQuery", "1.12.4.1", "2.2.4.1") }} \ I got an error about the version I want not falling into the constraints: ERROR: Cannot install horizon==23.1.2.dev2 because these package versions have conflicting dependencies. INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon:The conflict is caused by: INFO:kolla.common.utils.horizon: horizon 23.1.2.dev2 depends on XStatic-jQuery<2 and >=1.12.4.1 INFO:kolla.common.utils.horizon: The user requested (constraint) xstatic-jquery==2.2.4.1 There is no version of XStatic-jQuery after 1.12.4.1 and before version 2, so that failed. We see this in https://github.com/openstack/horizon/blob/d205ff09bed65b08960c3578434060eac… Finally, I decided to try: && {{ macros.upper_constraints_remove("XStatic-jQuery") }} \ && {{ macros.install_pip(['pip', 'wheel', 'XStatic-jQuery==3.*']) }} \ And it looked like it was working: INFO:kolla.common.utils.horizon:Collecting XStatic-jQuery==3.* INFO:kolla.common.utils.horizon: Downloading xstatic_jquery-3.7.1.1-py3-none-any.whl.metadata (888 bytes) [...] INFO:kolla.common.utils.horizon:Downloading xstatic_jquery-3.7.1.1-py3-none-any.whl (306 kB) INFO:kolla.common.utils.horizon:Installing collected packages: XStatic-jQuery INFO:kolla.common.utils.horizon:Successfully installed XStatic-jQuery-3.7.1.1 Until later in the build, when it tried to build version 1.12.4.1: INFO:kolla.common.utils.horizon:Collecting XStatic-jQuery<2,>=1.12.4.1 (from horizon==23.1.2.dev2) INFO:kolla.common.utils.horizon: Downloading XStatic-jQuery-1.12.4.1.tar.gz (123 kB) INFO:kolla.common.utils.horizon: Installing build dependencies: started INFO:kolla.common.utils.horizon: Installing build dependencies: finished with status 'done' INFO:kolla.common.utils.horizon: Getting requirements to build wheel: started INFO:kolla.common.utils.horizon: Getting requirements to build wheel: finished with status 'error' So my question is: How do I just get Kolla to build 3.7.1.1 while ignoring version 1.12.4.1?

1 1

[nova][ironic] Nova-Compute Ironic placement sync
by Nathan Harper 30 Jun '26

30 Jun '26

Hi Openstackers! We have been increasing our bare metal estate with almost all workloads driven by nova-compute-ironic. We have instance of nova-compute-ironic that we’ve moved from the default availability zone, but we discovered that the bare metal resource providers don’t get moved to the parent aggregate (associated with the AZ). Running nova-manage placement sync_aggregates by hand gives: Unexpected number of compute node records (91) found for host conductor2-ironic. There should only be a one-to-one mapping. I would guess that this is a nuance of how nova-compute-ironic is modelling the compute resources and is sufficiently different from the default 1:1 nova-compute -> hypervisor mapping. My question is: Is the expected behaviour? We can move the resource providers to the right aggregate using openstack resource provider aggregate set --aggregate but I’d be interested to know if there is another way? How are others handling this? Thanks! -- 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