March 2026 - openstack-discuss - lists.openstack.org

Next Digital Sovereignty WG Meeting
by Kendall Nelson 17 Mar '26

17 Mar '26

Hello Everyone! I hope you enjoyed the bye-week; it's time to vote on the next meeting time <https://beta.framadate.org/polls/8529564824278c0ca549>! The next meeting will take place March 17th, 18th or 19th depending on your responses. You have until March 15th to reply to the poll. As for the other in progress items we have: - Allison is drafting sample stances for us to review and select during the meeting - those drafts will be added to the etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG> before the end of the week. - It doesn't look like anyone has been brave enough to jump in and start the comparison sheet <https://docs.google.com/spreadsheets/d/1XhJoB88pkWf26w1JWuo5KqSTrQicTiTZY14…> nor the best practices guide <https://docs.google.com/document/d/1Pv02JFm58k-hefgSQ0_4fgsWQO0erqe42JRZz6I…> so I will try to add some content ahead of the meeting to get the ball rolling unless someone else gets there first! - We currently have three volunteers for doing thought leadership pieces in this space - are there any other volunteers? - Anyone that volunteered to provide a case study is encouraged to begin that work if it has not already been started as we will be touching on updates during the call as well! Did I miss anything? Any questions? If not, please respond to the poll and we will see each other soon! -Kendall

2 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-2)
by Goutham Pacha Ravi 17 Mar '26

17 Mar '26

Hello Stackers, We're two weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Last week, we began tagging release candidates for all deliverables following the "cycle-with-rc" release model. There are a few stragglers [2], but the release team hopes to wrap up soon. These candidate builds should assist the community in testing, finding, and patching any release-critical issues for a timely release on April 01, 2026. It's the last couple of days for the PTL Elections for the 2026.2 cycle [3]. If you are an Active Project Contributor in Horizon and Barbican projects, and an OpenInfra Foundation Individual Member who hasn't voted yet, please do exercise your vote. If you're having trouble finding your ballot, please reach out to election officials via this email list or ping them within #openstack-election on OFTC. In the past week, the OpenStack Technical Committee elected its Chair and Vice Chair. I'll be continuing as Chair, and Michal Nasiadka (mnasiadka) will continue as Vice-Chair. We've refreshed our team liaisons as well: Sylvain Bauza (bauzas) and I (gouthamr) will continue as Vulnerability Management Team (VMT) liaisons, and Amy Marrich (spotz[m]) will be our Election liaison. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on March 10, 2026 [4]. For the past release, the TC has been meeting on Tuesdays at 1700 UTC, and hosting a monthly meeting at 0800 UTC, a more friendly time slot for contributors in the Eastern Hemisphere. However, with "daylight savings" changes wrecking our calendars a bit, we've decided to run a poll to re-plan our meeting times and formats closer to the OpenInfra PTG (April 20-24, 2026). In the meantime, we'll be keeping the usual meeting slot on Tuesdays at 1700 UTC, and pausing the APAC friendly meeting temporarily. Talk about timezones being challenging. We revisited leaderless project teams. The governance patches for appointing PTLs to Adjutant, Mistral, Skyline, Requirements and Oslo are up on Gerrit and ready to merge once the election results land. Dmitry Robotyegov (noonedeadpunk) volunteered to kick off the retirement process for Venus and Vitrage. Dr. Jens Harbott (frickler) will propose a resolution to credit core reviewers (code-review +/-2, workflow +1) as contributors in our election process—this would cover cases where a core reviewer can't run as PTL because they were only reviewing and approving changes without any patches of their own. Jeremy Stanley (fungi) will improve the election tooling once a resolution is approved. On the CI front, we've picked up a new tox release that broke things and required temporary pinning in our CI jobs [5]. frickler and noonedeadpunk landed fixes, which prompted a broader conversation about migrating from tox to nox, as OpenDev and Zuul did years ago. nox has its benefits—it uses standard packaging tools rather than reimplementing its own—but switching at this point is a lot of effort. It could be worth exploring as a community goal if there's enough interest. The next meeting of the OpenStack TC is Tuesday March 17, 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 [6]. I hope to see you there. === Governance Proposals === ==== Merged ==== - Add TC chair and vice-chair for 2026.2 | https://review.opendev.org/c/openstack/governance/+/979922 ==== Open for Review ==== - Retire requestsexceptions | https://review.opendev.org/c/openstack/governance/+/979815 - Restore DPL model for requirements project | https://review.opendev.org/c/openstack/governance/+/977547 - Revert "Reset the DPL model for Oslo project" | https://review.opendev.org/c/openstack/governance/+/977707 - Appoint Arnaud Morin as PTL for mistral | https://review.opendev.org/c/openstack/governance/+/977344 - Appoint Wenxiang Wu as PTL of Skyline | https://review.opendev.org/c/openstack/governance/+/978067 - Appoint Callum Dickinson as PTL for Adjutant | https://review.opendev.org/c/openstack/governance/+/978842 - Revert "Revive os_monasca" | https://review.opendev.org/c/openstack/governance/+/974775 === Upcoming Events === - 2026-03-23: KubeCon/CloudNativeCon EU: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2026-04-01: 2026.1 "Gazpacho" coordinated release - 2026-04-02: OpenInfra Live: https://openinfra.org/live/ - 2026-04-14: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-04-20: OpenInfra PTG begins: https://openinfra.org/ptg/ - 2026-04-25: OpenInfra Days, Nigeria: https://www.meetup.com/openstack-nigeria-user-group/events/313525373/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] 2026.1 RCs: https://review.opendev.org/q/topic:%22gazpacho-rc1-deadline%22+(status:open… [3] OpenStack 2026.2 PTL Elections: https://governance.openstack.org/election/ [4] TC Meeting IRC Log, March 10 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-10-17.00.html [5] Tox pinning fix: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/979118 [6] TC Meeting Agenda, March 16 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

OpenStack RPMs - Call for packaging volunteers
by Francesco Di Nucci 16 Mar '26

16 Mar '26

Hi all, the RDO Project[0], that provided OpenStack RPM packages through the CentOS Cloud SIG, is switching to a container-based approach due to lack of maintainers.[1] This means *there will be no more RPM packages for OpenStack versions after 2025.1/Epoxy unless new maintainers come up*. *This is a call across the EL and OpenStack communities for volunteer maintainers of RPM build pipelines*. If you're interested you can: * Add your name to the dedicated Etherpad (https://etherpad.opendev.org/p/rdo-volunteers) * Register to the RDO devs mailing list (dev(a)lists.rdoproject.org) and ask for more information No previous experience with packaging/pipelines is required, just willingness to learn /Note: this email is being separately to different mailing lists. If you have subscribed to more than one and recieve it multiple times, sorry for the duplication./ Links [0] https://www.rdoproject.org/ [1] https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Francesco, another OpenStack on EL operator -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

1 0

[ops][keystone]Migration to Epoxy and KeyError: '$6$'
by federica fanzago 16 Mar '26

16 Mar '26

Dear all, we are running an OpenStack deployment Caracal on AlmaLinux 9.7 and we are attempting the upgrade to Epoxy release. Our cloud has been running since 2018, and over the years we have performed several release updates (Rocky-Train-Yoga-Caracal) without modifying the default value for the parameter "password_hash_algorithm" in the keystone.conf file During the update to Epoxy, Keystone shows an error in /var/log/httpd/keystone_wsgi_internal_error.log that seems related to the deprecation of older encryption algorithms 026-03-13 15:31:15.359556 ValueError: Unsupported password hashing algorithm ident: $6$ 2026-03-13 15:31:17.703201 mod_wsgi (pid=32730): Exception occurred processing WSGI script '/usr/bin/keystone-wsgi-public'. 2026-03-13 15:31:17.703935 Traceback (most recent call last): 2026-03-13 15:31:17.703966 File "/usr/lib/python3.9/site-packages/keystone/common/password_hashing.py", line 72, in _get_hasher_from_ident 2026-03-13 15:31:17.703972 return _HASHER_IDENT_MAP[hashed[0 : hashed.index('$', 1) + 1]] 2026-03-13 15:31:17.703994 KeyError: '$6$' In our db there are some passwords starting with "$6$round....". Do you any have suggestions about how to modify the encryption algorithm for these passwords to $2$? Is there a keystone script to perform this migration and fix the error? Thanks, cheers Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

2 2

[all][infra] releases.openstack.org is down, CI jobs relying on it are failing, hold any recheck
by Yatin Karel 16 Mar '26

16 Mar '26

releases.openstack.org is down for some reason and jobs failing like:- 2026-03-15 22:15:00.754677 | controller | WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x771c7273af90>: Failed to establish a new connection: [Errno 111] Connection refused')': /constraints/upper/master 2026-03-15 22:15:00.754693 | controller | ERROR: Could not install packages due to an OSError: HTTPSConnectionPool(host='releases.openstack.org', port=443): Max retries exceeded with url: /constraints/upper/master (Caused by NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x771c7273b230>: Failed to establish a new connection: [Errno 111] Connection refused')) Need someone from infra to check and bring this server up to unblock the CI. -- Thanks and Regards Yatin Karel

2 1

[requirements][horizon] Requirements freeze exception request
by Radomir Dopieralski 16 Mar '26

16 Mar '26

Hello, I would like to request a requirements freeze exception to bump the version of Django from 4.2.28 to 5.2.12. It is important for Horizon to ship with a version of Django that is security supported, and the security support for Django 4.2.8 ends next month. Django 5.2.12 is a long-term-support release, and will have security support for the next two years [1]. We have been working on making Horizon compatible with Django 5.2 in this release, but the disruption of the gates and the distractions caused by it in the last few weeks prevented us from getting the relevant patches merged on time for the freeze [2]. The patch for requirements is [3] [1] https://endoflife.date/django [2] https://review.opendev.org/c/openstack/horizon/+/973902 [3] https://review.opendev.org/c/openstack/requirements/+/979862 -- Radomir Dopieralski

9 12

[magnum] Magnum Cluster Template Creation Fails 'oslo.utils>=3.33.0' not found
by Shakko 16 Mar '26

16 Mar '26

Hi guys. First time writing here, so i hope i'm respecting every rule and that i chose the right tag. I'm experiencing this reported bug https://bugs.launchpad.net/kolla-ansible/+bug/2142434 when creating a template on my openstack 2025.2 kolla ansible installation. The 'oslo.utils>=3.33.0' distribution was not found, should be the problem. I did checked inside magnum_api container's venv and oslo utils was installed at version oslo.utils-9.1.0 Also tried to update it (now the version is oslo.utils-10.0.0) but nothing changes... So why is this happening? Anyone knows something about it? Any help would be really appreciated.

1 1

[watcher] Core team updates
by Douglas Viroel 14 Mar '26

14 Mar '26

Hi all, Following up on previous Sean's email[1], from Sep 8th 2025, regarding Watcher core team updates, I'd like to propose the following updates for 2026.2 cycle: 1. Core Removals As we start a new release cycle, the watcher core members mentioned in Sean's email for potential removal due to inactivity (*chenker[2], Dan Smith[3], Marios Andreous[4], and Slawek Kaplonski[5]*) will now be removed, effective immediately. I'd like to take this opportunity to thank all of them for their contributions to Watcher over the years. Maintaining an active core team is essential for the health of the project, and in the case of any of these contributors becoming active again in the future, we would welcome proposals to re-add them to the core team. 2. New Core Member Proposal I'd like to propose adding *Alfredo Moralejo (amoralej)* to both the *watcher-core* and *watcher-dashboard-core* groups. He has been consistently contributing to the Watcher project and has demonstrated a solid understanding of the codebase through quality reviews[6][7] and patches. Alfredo provides valuable feedback, helps with manual testing when needed, proactively file new bugs and assist on the bug triage process. I believe he would be a valuable addition to the core team. If there are no objections, the new core additions will be applied right after the next Watcher IRC meeting, next Thursday, Mar 19th, Please feel free to share any feedback or concern around these 2 proposed changes in the core team. Best regards, [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=chenk… [3] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=danms [4] https://review.opendev.org/q/reviewedby:marios.andreou@gmail.com [5] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=slaweq [5] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=amora… [6] https://www.stackalytics.io/?module=opendev.org/openstack/watcher-dashboard… -- Douglas Viroel - dviroel

1 0

[ironic][nova][ptg] Cross-project session around nova-compute startup
by Jay Faulkner 14 Mar '26

14 Mar '26

Hey all, A few releases back we swapped up the model for nova-compute HA in Ironic -- mainly, moved it in line with other nova drivers where the loss of a single nova-compute service takes down a portion of the cloud, but HA is achieved by having other portions of the cloud still available. This model has serious limitations in an Ironic world; including but not limited to: * Use cases around rebuilding into the same physical machine can never be isolated from an outage (including upgrades) * Even with a reasonable number of nodes managed, nova-compute processes managing Ironic nodes can take a long, long time to get online. We're talking 15-20 minutes with reports of even worse in some scenarios. I'd like to improve this story. It's operationally painful to eat a multi-minute long outage for a deployment of code to a server -- and given my use case of in-place rebuilds, there's no amount of aggregation of nodes which can get us clear of this issue. It's also clear that going back to a model which would run multiple nova-compute processes to manage the same machines is too incompatible with the general nova model; so instead I think we can try to tackle a major pain point: the slow startup. Ideas I have thought about to address this include: * Improving how resources are added to placement for Ironic, doing it incrementally from Ironic may reduce the number of calls needed at startup * Improving placement API interfaces to perhaps allow bulk updates, so we aren't doing "N" calls for "N" ironic nodes at startup, as I believe we currently do * Some method of "handoff" between a staged nova-compute service and one that is shutting down, so we can avoid the outage in properly coordinated update scenarios. (I'm not sure this is possible) One thing that's clear to me: I don't have the knowledge to pursue this alone. My hope is that we can work together at the PTG to determine one or more good, potential directions, then put together a spec during the Hibiscus cycle which could be implemented for "I" (not Icehouse :D). As long as we have a commitment from nova cores to perform reviews and help with the design, I should be also to provide resources (myself + maybe others) from the GR-OSS team to help implement it. Thanks! Jay Faulkner Open Source Developer G-Research Open Source Software

1 0

[release] Release countdown for week R-2, Mar 16 - 20
by Elõd Illés 14 Mar '26

14 Mar '26

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2026.1 Gazpacho deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2026.1 branch creation for all deliverables that have not branched yet, using the latest available 2026.1 Gazpacho release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2026.1 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2026.1 branch before releasing out of the stable/2026.1 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2026.2 Hibiscus development, though the focus should still be on finishing up 2026.1 Gazpacho until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2026.1 Gazpacho release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targetted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2026.1 Gazpacho version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: March 26th, 2026 (R-1 week) 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