- openstack-discuss - lists.openstack.org

[openstack-helm] Remove metacontroller and daemonjob-controller
by Vladimir Kozhukalov 27 Mar '26

27 Mar '26

Hi team, I noticed very little interest in maintaining the two charts: metacontroller and daemonjob-controller. If there are no objections I suggest removing them from the OpenStack-Helm project. -- Best regards, Kozhukalov Vladimir

1 1

[glance][swift][2026.1] Glance fails on image download from Swift
by Dmitriy Rabotyagov 27 Mar '26

27 Mar '26

Hi folks, I am trying to test out Glance configured with Swift backend on 2026.1 prior to the release, and facing some issues. As we are super close to the release, I have decided to pop up with the ML, to ensure it's a "me" problem, and not a generic bug somewhere. So I am using: - Glance installed from SHA 07dd0a203b6883efa66486035c436b92c83da0f3 - glance-store 5.4.0 (according to U-C) - Swift installed from SHA 51b068309a626d2228ab69b5158ee857e96d101d Image upload works quite well [1], image is appearing in Glance and in Swift quite correctly. But whenever I attempt to create an instance from the image, or, basically, just download image with `openstack image save a024ca39-42bc-4a0c-bd34-26209bda4008`,I get Glance WSGI crashing, resulting in 502: root@aio1-utility-container-20f6bf88:/# openstack image save a024ca39-42bc-4a0c-bd34-26209bda4008 Unable to download image: checksum mismatch (sha512): 9a9bce0083a00939ec17c11febbfc767aa211aaa54f51e75c5a8b271a9b5637c77205a518b7a2007cb391d23cceb01e0e4e8d64832317151bc85b734b92a7be0 != a3b1ae48ab757e1e074c33c3159cb3bc749d0119677446b442 c5568eeaf2a4d741d794ca9750e13c3352b7db073d0f9101670f3cbede942df3f5fdb12024aaca <html><body><h1>502 Bad Gateway</h1> The server returned an invalid or incomplete response. </body></html> root@aio1-utility-container-20f6bf88:/# The actual crash and stack trace can be seen here [2]. With that, I can download the image with Swift client without any issues [3], and checksum matches. This result is pretty much reproducible, and I get it constantly in OpenStack-Ansible's CI jobs, for example [4] With that, I have the impression that something goes terribly wrong on the Glance side of things in combination with Swift, as CI jobs using Ceph or File backends are working normally. Given where we are release-wise, I'd love to ask for some help investigating this problem... [1] https://paste.openstack.org/show/bjdhtY2p33L4g0CTTdqH/ [2] https://paste.openstack.org/show/bRhFaEdoJotDngNXBjlB/ [3] https://paste.openstack.org/show/badVIJc0hwqbsy5X3Iv3/ [4] https://zuul.opendev.org/t/openstack/build/0be7ba6d8f854c0a88df9f9e33461d20…

2 4

[horizon] code that depends on openstack_dashboard in Horizon plugins
by Radomir Dopieralski 27 Mar '26

27 Mar '26

There has been recently some discussion, in the context of Horizon releases, about the dependencies Horizon's plugins have on different part of Horizon [1]. It was mentioned there that some plugins import from the openstack_dashboard python package, not just from the openstack_auth and horizon libraries. This is a bit worrying, because as far as I can remember, the idea behind splitting the code into several python packages was to allow the libraries to use the common code that is supposed to be reused, and keep the application-specific code that can change at any moment separate from that. So I went ahead and looked at all the plugins and at what exactly they import from openstack_dashboard: * openstack_dashboard.urls, openstack_dashboard.utils.settings, openstack_dashboard.test.helpers, openstack_dashboard.enabled: tests in almost all plugins * openstack_dashboard.exceptions: mistral-dashboard, charm-openstack-dashboard, watcher-dashboard, openstack-helm, openstack-ansible-os_horizon * openstack_dashboard.api: networking-bgpvpn, tacker-horizon, heat-dashboard, manila-ui, cloudkitty-dashboard, magnum-ui, heat-dashboard, neutron-vpnaas-dashboard, adjutant-ui * openstack_dashboard.policy: tacker-horizon, neutron-fwaas-dashboard, heat-dashboard, blazar-dashboard, trove-dashboard * openstack_dashboard.dashboards.project.instances.utils: trove-dashboard Looking at this list, we can see a few obvious candidates to be moved to either the openstack_auth or the horizon package. The dependency on openstack_dashboard.api is worrying, especially since we are going to rewrite that part entirely to use openstack_sdk and not the deprecated python-openstack-*-client libraries. Perhaps it would not hurt to have the plugins duplicate some of that code, to avoid breaking when we do that. The last one is an outlier, and I'm sure it could be fixed. The test dependencies are a little bit more tricky, because they are mostly copy-pasted code from Horizon's own tests. Some of that code is already deprecated and scheduled for removal in Horizon, the rest should be probably either moved to the horizon package or duplicated. I would be interested to hear from the plugin developers about their opinions on this. Note that my search only included python code. It would be a bit more work to also find any javascript, scss, and template dependencies, if they exist. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

[release] Release countdown for week R+0, Mar 30 - Apr 03
by Elõd Illés 27 Mar '26

27 Mar '26

Development Focus ----------------- We will be releasing the coordinated OpenStack 2026.1 Gazpacho release next week, on April 1st, 2026. Thanks to everyone involved in the 2026.1 Gazpacho cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: https://ptg.opendev.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 1st, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2026.1 "Gazpacho" release: April 1st, 2026 2026.2 "Hibiscus" (virtual) PTG: April 20-24, 2026 Előd Illés irc: elodilles @ #openstack-release

1 0

Status of Debian packages for Gazpacho
by Thomas Goirand 27 Mar '26

27 Mar '26

tl;dr: Gazpacho Debian packages are ready and tempest validated! Hi, Just wanted to write a quick message to tell the community that I have been able to mostly validate all of the Gazpacho release, a few days before the final release. The last issues in glance-store and os-ken (upstream bugs in these components) have been addressed quickly, thanks to the reactivity of both Abhishek Kekane and lajoskatona respectively, which is very much appreciated! As the issue with os-ken prevented my CI to properly test Octavia and other stuff, I'll restart the tests, however, results are showing that everything else seems working. As always, the packages are available through the unofficial osbpo.debian.net repositories if you wish to use the backports to Debian Stable (Trixie), which can be managed with extrepo: apt-get install extrepo extrepo enable openstack_gazpacho apt-get update I'm at the moment uploading everything to Debian Unstable as well, even if this currently means that I'm uploading the RC releases. Thanks to everyone involved in this release. OpenStack continues to be an awesome community to work with! I sincerely hope my constant efforts to have always up-to-date Debian package as soon as possible, with enough unit and functional tests to guarantee a quality standard will continue to help Debian users, Cheers, Thomas Goirand (zigo) P.S: The real-time status of OpenStack Debian packaging continues to be available at https://osbpo.debian.net/deb-status/

2 1

Upcoming metrics dashboard changes
by Ildiko Vancsa 27 Mar '26

27 Mar '26

Hi OpenStack community, Since the OpenInfra Foundation joined the Linux Foundation, we have been looking into opportunities to take advantage of the frameworks and tool sets that the Linux Foundation has, and some of you and your organizations are already familiar with. While the dashboards are still being built I would like to let you know that, as part of that effort, we will switch to LFX Insights[1] as the metrics dashboard for OpenInfra projects, including OpenStack, starting on __January 15, 2026.__ A couple things to note: - The new OpenStack metrics dashboard[2] is already available, but it is __still under active construction.__ - The set of metrics that is displayed on the new dashboard will not be identical with the metrics on the dashboard provided by Bitergia. - LFX Insights does not display affiliation information for individuals who are listed on the dashboard as contributors, for privacy reasons. However, if you already have an LF account[3], you will be able to check and update your affiliation information. Or, you can create a new LF account[4]. - You can learn more about the dashboard in the LFX Insights documentation[5]. - If your organization is an OpenInfra Foundation / Linux Foundation member already, the LF Organization Dashboard[6] is also available for a more company-centric view. The OpenStack Bitergia metrics dashboard[7] remains available __until January 14, 2026.__ Please let me know if you have any questions. Best Regards, Ildikö [1] https://insights.linuxfoundation.org/ [2] https://insights.linuxfoundation.org/project/OpenStack/ [3] https://openprofile.dev/ [4] https://docs.linuxfoundation.org/lfx/sso/create-an-account [5] https://insights.linuxfoundation.org/docs/introduction/what-is-insights/ [6] https://lfx.linuxfoundation.org/tools/organization-dashboard/ [7] https://openstack.biterg.io/ ——— Ildikó Váncsa Director of Community OpenInfra Foundation

4 9

Status of Debian package for Gazpacho
by Thomas Goirand 27 Mar '26

27 Mar '26

tl;dr: Gazpacho Debian packages are ready and tempest validated! Hi, Just wanted to write a quick message to tell the community that I have been able to mostly validate all of the Gazpacho release, a few days before the final release. The last issues in glance-store and os-ken (upstream bugs in these components) have been addressed quickly, thanks to the reactivity of both Abhishek Kekane and lajoskatona respectively, which is very much appreciated! As the issue with os-ken prevented my CI to properly test Octavia and other stuff, I'll restart the tests, however, results are showing that everything else seems working. As always, the packages are available through the unofficial osbpo.debian.net repositories if you wish to use the backports to Debian Stable (Trixie), which can be managed with extrepo: apt-get install extrepo extrepo enable openstack_gazpacho apt-get update I'm at the moment uploading everything to Debian Unstable as well, even if this currently means that I'm uploading the RC releases. Thanks to everyone involved in this release. OpenStack continues to be an awesome community to work with! I sincerely hope my constant efforts to have always up-to-date Debian package as soon as possible, with enough unit and functional tests to guarantee a quality standard will continue to help Debian users, Cheers, Thomas Goirand (zigo) P.S: The real-time status of OpenStack Debian packaging continues to be available at https://osbpo.debian.net/deb-status/

1 0

Windows Instance Performance - Possible issues with VirtIO Drivers
by Joel McLean 27 Mar '26

27 Mar '26

G'day Openstackers. I've found myself down a rabbit hole that I think will get me nowhere; but I wanted to query the list to see whether people are seeing the same, or whether what I'm experiencing can be mitigated, if someone here has seen this behaviour. We are running an Openstack (caracal 2024.1) with Libvirt/qemu as the guest agent. Storage is all cinder volumes on a stand-alone storage platform - an NVMe Ceph (reef) Cluster provided to Openstack via Cinder. For Windows virtual machines, we are installing VirtIO drivers ( https://docs.openstack.org/image-guide/create-images-manually-example-windo… ) and have tried a variety of driver versions (0.1.285-1, 0.1.271-1, 0.1.262-2, 0.1.248-1) and while they all work, we have noticed significant different in performance between throughput and IO operations compared to virtual machines running on Ubuntu. The performance differences are most notable in a real-world workload test using - a MySQL 8 database - same CPU and Memory Configuration Flavor, same volume_type - same MySQL configuration - we run a query that checks for missing indexes, then creates ~500K missing indexes. On the Ubuntu 24 instance the task completes in ~17 minutes, On the Windows 2025 instance, the task completes in ~29 minutes. Testing to compare against a Hyper-V compute host, with the same performance drives, except as locally attached NVMe drives, performance for the same task in Windows 2025 is ~17 minutes. Testing the windows instance with different VirtIO (vioscsi, or viostor) didn't significantly impact the task completion time; it averaged between 29 and 35 minutes depending on which driver was in use. In Ceph, there's no errors to speak of, all logs are nominal in Ceph when comparing RBD claims (i.e. Linux vs Windows) So, we're pretty sure the issue is how Windows Instances consume storage. This behaviour is consistent with the performance problems described in this issue: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1482 Has anyone else experienced this issue, or found a way to work around it? Let me know if there's any more information that I could provide that might give some insight into the matter. Kind Regards, Joel McLean https://www.micron21.com/ 1300 769 972 03 9751 7618 0407 888 429 joel.mclean(a)micron21.com Follow us on Twitter and https://m21status.com for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

2 3

[qa] Tempest gate is blocked
by Ghanshyam Maan 26 Mar '26

26 Mar '26

Hi all, Tempest gate is currently blocked because tempest-tox-plugin-sanity-check is failing 100%. Please do not recheck until the below fix is merged: - https://review.opendev.org/c/openstack/tempest/+/982305 -gmaan

1 0

[ironic] Hardware type / interfaces removal: SNMP, iRMC, iLO
by Jay Faulkner 26 Mar '26

26 Mar '26

Hey all, We are removing some deprecated drivers in the 2026.2 release. Already posted for removal are the iRMC (Fujitsu) and SNMP driver, which have both been deprecated for removal for a while and are the primary cause of some libraries being version-locked in upper-constraints.txt (sorry Requirements team). I would additionally like to propose we remove the legacy iLO driver as well. Back in 2024.1 release, Ironic added a release note indicating a general plan to deprecate the iLO hardware types with no timeline. In the 2025.2 release, we formally announced the deprecation and added an upgrade check to warn operators using the iLO driver still to migrate off. Now on the horizon of the 2026.2 release, it seems to be time to sunset this driver for good. The proliantutils library it relies on has been unmaintained for a long time and no Ironic community members have access to merge changes on it, and I have a concern that we may be shipping a non-working driver due to this library abandonment. All modern iLO hardware are well-supported by the generic redfish driver. Please scream loudly now if you oppose, or else the iLO driver will be gone this release. Thanks, Jay Faulkner Open Source Developer G-Research OSS

1 0