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

[all][elections][ptl][barbican][horizon] PTL 2026.2 cycle Election Voting Last Days
by Ian Y. Choi 19 Mar '26

19 Mar '26

We are coming down to the last hours for voting in the Barbican, Horizon elections. Voting ends Mar 18, 2026 23:45 UTC. Search your Gerrit preferred email address[0] for the messages with subjects like... OpenStack 2026.2 Cycle - Barbican PTL Election Poll OpenStack 2026.2 Cycle - Horizon PTL Election Poll That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/ What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * find the ID of at least one commit merged to an official deliverable repo[1] over the current and previous cycles, confirm you are an Open Infrastructure Foundation Individual Member[2], and then email the election officials[3] or get in touch in the #openstack-election channel on the Freenode IRC network. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org and go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [2] https://www.openstack.org/profile/ [3] https://governance.openstack.org/election/#election-officials

1 0

[qa] Canceling today QA office hour
by Ghanshyam Maan 19 Mar '26

19 Mar '26

Due to another conflict, I will cancel today's office hour. The next office hours will be on 1st April. https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Details -gmaan

1 0

[cinder] festival of reviews friday 2026-03-20
by Brian Rosmaita 18 Mar '26

18 Mar '26

Hello Argonauts, It's already the third week of March, which means that the twice monthly Cinder Festival of Reviews will be held at the end of this week on Friday 20 March. who: Everyone! what: The Cinder Festival of Reviews when: Friday 20 March 2026 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

March 17 Digital Sovereignty Meeting Recording & Plan Going Forward
by Kendall Nelson 18 Mar '26

18 Mar '26

Hello Everyone! Thank you to those who were able to attend yesterday's meeting. We really appreciate you taking time out of our day to support collaboration around OpenInfra and Digital Sovereignty. For those that were unable to attend, here is the recording! https://zoom.us/rec/share/5C87PC0AwqXFVCeW-f0ydLppVrEsUSuvRyV_M9xSgvPcVq7ZF… As always, please note in our etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG> that you have watched the recording and feel free to add your own notes as well. Just because you are not able to make it to all the meetings, doesn't mean you don't have valuable insight - we want to hear from you. Now, as to how our efforts are going - since we are in a good place with the landing page, link coming soon - we are going to take a few weeks to break into smaller groups to work on some of the deliverables and make our next big meeting during the PTG (April 20-24) with that exact timing TBD via a poll in a couple weeks. *If there is a particular deliverable (case studies, best practices, proprietary v openstack, and thought leadership blogs) please make sure to add your name to those sections (and email address to the attendees section) of the etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG> by the end of the week so I can set up individual threads for those subgroups. * Any questions? Please feel free to ask! -Kendall

1 0

[cinder][ops] Migrate volume backend from decommissioned node
by Isaac Vicente 18 Mar '26

18 Mar '26

Hello all, In the past week I've added a new controller and decommissioned an old one, following the official documentation [1], and I wrote a version of my own [2], specific to my environment. In the section "Removing existing controllers", it's necessary to move agents and remove services of the node that will be decommissioned. So far so good, until I realize that a volume has the following property: os-vol-host-attr:host: <old_node>@rbd-1#rbd-1 It means that this volume is still on the backend of the removed node. So I tried to migrate it to another backend, and the migration status is "starting" for a long time. In the cinder-scheduler logs: WARNING cinder.scheduler.host_manager volume service is down. (host: <old_node>@rbd-1) To me, the migration stays in this status because the proper backend is down. To mention, I'm using Ceph as cinder backend. Also, there's no mention of the volume being migrated on other controller nodes. Is there any method to migrate all volumes of this backend without needing to re-deploy the old controller? Versions: - Openstack: caracal (2024.1) - OS: Ubuntu 22.04 - kolla-ansible: 18.8.1 [1] https://docs.openstack.org/kolla-ansible/latest/user/adding-and-removing-ho… [2] https://isaacvicente.github.io/posts/replacing-control-nodes-with-kolla-ans…

3 4

[docs] Documentation sites are extremely slow
by Eugen Block 18 Mar '26

18 Mar '26

Hi, I'm not sure how long it has been like that, but when I tried to access the documentation yesterday, it took forever to load. And it is the same today, it takes several minutes to load any site, for example: https://docs.openstack.org/cinder/2025.2/admin/ I tried it from different networks, didn't make a difference. Is that a known issue? Thanks, Eugen

5 7

[dev][nova] Intel TDX support
by Anton Iacobaeus 18 Mar '26

18 Mar '26

Hi, I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova. I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release. From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed. Early feedback or any concerns and guidance are very welcome! [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support Best Regards, Anton

4 4

[Masakari] team meeting today at 07:00-08:00 UTC
by Sei Sano 18 Mar '26

18 Mar '26

Hi team Apologies for the short notice ― just a reminder that we have our regular team meeting today. When: 07:00 UTC, <day>, <date> Where: #openstack-masakari (OFTC) Agenda: https://etherpad.opendev.org/p/masakari-meeting-2026.1 If you have any topics to discuss, please add them to the agenda. Thanks, Sei Sano

5 8

[PTG 2026.2] Scheduled Time Slots for Ironic Sessions
by CID Onyedikachi 18 Mar '26

18 Mar '26

Hello Everyone! Ironic PTG sessions have been scheduled for Monday through Friday, 20 - 24 April, 13:00 - 17:00 UTC in the Mitaka room. If any slot doesn’t work for you, a different time can be arranged. Feel free to reply to this email if a change is needed. -Afonne-CID (cid)

2 1

[cinder][backup] BackupManager.restore_backup() missing 1 required positional argument: 'volume_is_new'
by Eugen Block 17 Mar '26

17 Mar '26

Hi, my environment is: Epoxy on Ubuntu 24.04 package-based installation I'm looking for some clarification regarding this bug report [0]. I don't really understand if it's fixed or not. I was trying to rollback a volume to its backup version when I got this stack trace: Backup service: cinder.backup.drivers.ceph.CephBackupDriver. 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server [None req-54d97a73-522d-411a-9982-1f6bb0ea905b 89c5dcc8793d4867bae22d50e51e16b3 90c403f317ee47feb0dad58461e76fb1 - - - -] Exception during message handling: TypeError: BackupManager.restore_backup() missing 1 required positional argument: 'volume_is_new' 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/server.py", line 174, in _process_incoming 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/cinder/utils.py", line 1053, in wrapper 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server TypeError: BackupManager.restore_backup() missing 1 required positional argument: 'volume_is_new' It's stated that it was fixed in cinder versions 22 and 23, we are on Epoxy (cinder v 26) and still hit that issue. I then manually applied [1] which seems to have fixed the "volume_is_new" issue, at least I can restore volumes now. But I was also wondering why it took so long, and noticed that it doesn't keep the sparseness (although it should according to [2]. Here's the 'rbd du' output from a successfully restored volume: rbd du volumes-ssd/volume-6a9a8497-eacd-490e-be3e-f6dbdf638b5d NAME PROVISIONED USED volume-6a9a8497-eacd-490e-be3e-f6dbdf638b5d@backup.db61467a-5c29-4fca-b393-a1962dc6d2a8.snap.1773736256.760678 40 GiB 4.9 GiB volume-6a9a8497-eacd-490e-be3e-f6dbdf638b5d 40 GiB 40 GiB <TOTAL> 40 GiB 45 GiB I didn't expect that. Could anyone help me understand? Thanks! Eugen [0] https://bugs.launchpad.net/cinder/+bug/2025277 [1] https://review.opendev.org/c/openstack/cinder/+/914775 [2] https://bugs.launchpad.net/cinder/+bug/2007615

1 0

[kolla] Proposing Bertrand Lanson for kolla-reviewers
by Michał Nasiadka 17 Mar '26

17 Mar '26

Hello, I’d like to propose Bertrand (blanson) for being a member of the new kolla-reviewers group in Gerrit. That group is a step entry into being a core member of the project - gives +2 right without workflow. Bertrand has been very active in both code submissions and reviews and has solved some of the Podman issues that we have. If nobody opposes - I’ll add Bertrand in a week from now. Cheers, Michal

2 2

[oslo] Proposal to add Ghanshyam Maan as core team
by Daniel Mats Niklas Bengtsson 17 Mar '26

17 Mar '26

Hi everyone, I hope you are all doing well. I would like to propose adding Ghanshyam Maan to the oslo core team. Ghanshyam has been actively contributing to the Oslo libraries for some time. He regularly participates in technical discussions, including work around multiprocessing, provides thoughtful and constructive code reviews, and has contributed several solid patches. He is also currently serving as the TACT-SIG liaison and has offered to take on the role of release liaison as well. His consistent involvement in reviews and project discussions demonstrates a strong commitment to the Oslo projects and to the OpenStack community. I believe he would be a great addition to the oslo core team. Please reply with your votes (+1 / 0 / -1). The vote will remain open for one week.

3 2

[neutron] bug deputy report for week of 2026-03-09
by Bence Romsics 17 Mar '26

17 Mar '26

Hi Team, we have received the following new bug reports. Sorry for not sending this earlier. Critical: * https://bugs.launchpad.net/neutron/+bug/2144313 ovn-db-sync-util for SB sync crashes with ValueError: driver cannot be None fix merged on master: https://review.opendev.org/q/If9cb2e2d1e8b8479a7fc745e0eba9214b5869ec4 High: * https://bugs.launchpad.net/neutron/+bug/2143837 Neutron-fwaas logging driver breaks fwaas extension fix merged: https://review.opendev.org/q/I2b53029fbd3fcc67ab630bc4927a7845bedc6663 * https://bugs.launchpad.net/neutron/+bug/2143901 FWaaS logging driver is not loaded correctly by the neutron server fix merged on master: https://review.opendev.org/q/I5d413123f48ae644d20311abb529983d1830d2dd * https://bugs.launchpad.net/neutron/+bug/2144307 neutron-ovn-db-sync-util is missing required mechanism drivers to be loaded fix merged: https://review.opendev.org/q/I56b3711dc3ed7676de886295aefc3bba24659b77 Medium: * https://review.opendev.org/c/openstack/neutron/+/979705 Neutron can't parse OVN chassis name if it was added via 'ovn-nbctl' command original fix attempt turned into a doc patch: https://review.opendev.org/c/openstack/neutron/+/979705 Low: * https://bugs.launchpad.net/neutron/+bug/2144371 [OVN] Limit and document the IP+MAC AAP, restricted to VRRPv3 wip patch: https://review.opendev.org/c/openstack/neutron/+/980553 Stable: * https://bugs.launchpad.net/neutron/+bug/2143707 [stable][before 2025.1] fullstack fips jobs broken unassigned Wontfix: * https://bugs.launchpad.net/neutron/+bug/2144524 Neutron API returns all ports globally for admin-scoped requests, unlike Nova which scopes by project Incomplete: * https://bugs.launchpad.net/neutron/+bug/2144312 [OVN] Virtual ports should not update the host ID in the VIF details Other: * https://bugs.launchpad.net/neutron/+bug/2143892 [OVN] Test the creation of a "chassisredirect" port for LSP in routers connected to tunnelled networks unassigned, tracking ticket for new tests to be written * https://bugs.launchpad.net/neutron/+bug/2143895 Migrate policy objects to neutron-lib assigned to Slawek, code move to n-lib * https://bugs.launchpad.net/neutron/+bug/2143812 Router extraroute validation rejects nexthops from other subnets on same external network waiting for reporter feedback Still looking at it: * https://bugs.launchpad.net/neutron/+bug/2144501 NetworkContext excludes dynamic segments, breaking hierarchical binding cleanup Cheers: Bence

1 0

[all][elections][ptl][tc] Combined PTL/TC 2026.2 cycle Election Nominations End
by Ian Y. Choi 17 Mar '26

17 Mar '26

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 8 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Masakari, Mistral, Oslo, Requirements, Skyline, Venus, Vitrage There are 2 projects that will have elections: Barbican, Horizon. -- TC Election Details -- The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Feb 25, 2026 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#ptl-candidates [1] https://governance.openstack.org/election/#tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

3 3

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

[ci infra] local PyPi cache/mirroring/proxy
by Radomir Dopieralski 13 Mar '26

13 Mar '26

Hello, I don't really have much more than surface experience with our CI infrastructure, but I wanted to start a discussion on a topic that maybe could be picked up by more knowledgeable colleagues. Our tests install a lot of python packages. It almost feels like more than half the time of any test run is spent installing packages. By default, all those packages are being installed from PyPi directly. I wonder if we could gain some advantages by running a local PyPi cache or mirror inside of the CI infrastructure, and making all those tests use it by default for all its package installs. It would: - speed up the downloading of packages, - make tests more resilient in the face of outside network or PyPi outages, - make us better citizens by decreasing the traffic to PyPi and conserving their resources, - give us more control over which packages are available (so, for example, we could easily pin setuptools for all tests, or ban a particular known bad package version, or even do pre-releases of our own packages before we release them on PyPi), Of course nothing is for free, and such a service would require some extra work to set up and maintain. I don't have the experience to be able to tell if the overhead is worth it, but maybe it's something worth considering? Or maybe we are already doing this, and I'm just wasting everyone's time? There is a number of ready to use tools we could utilize for this: https://packaging.python.org/en/latest/guides/index-mirrors-and-caches/#exi… What do you think? -- Radomir Dopieralski

2 2

[neutron] OVN version used in the functional gate job
by Jakub Libosvar 13 Mar '26

13 Mar '26

Hi all, I wanted to bring this topic up for a discussion again. I’ve been working on a Neutron feature [1] for some time, the feature requires the BGP support in OVN. The functional job currently uses a moving OVN branch based on the OVN LTS version - which is 24.03 - almost 2 years old. I tried to change this and requested a patch to switch to using a pinned OVN mostly for two benefits: - we won’t get gate broken if a bad patch is backported to the branch-24.03 - I get the BGP features needed for the work on [1] The patch was denied to keep the policy we set on ourselves - ie. to go with the branch based on the OVN LTS version. The workaround was to skip multiple tests that rely on the OVN changes specific to BGP. This is not ideal as now majority of the functionality is not tested and we’re just waiting for the LTS release, which may bring some surprises. This was a concrete example but if we put it into a more general situation, in Neutron we heavily rely on OVN and its features and any development of a potential feature that requires some work in OVN gets cumbersome because we can’t validate our code against OVN until the point a next OVN LTS version is released, which in the worst case scenario can take up to 2 years. Hence I propose a change and use a pinned hash from the OVN tree that is updated on two occasions: - A next OVN version is released (non-LTS) - We’re developing a feature that relies on bleeding edge OVN - then we pick a good hash and pin to it in the functional job definition (not in the scripts) This would apply solely to the functional tests because tempest jobs can define their own OVN version and unit tests should be isolated from the used OVN version, and only to the master branch - because that is the development branch after all. Such a change brings multiple benefits, we won’t need to skip tests if the required functionality is not present in current OVN version and have the development go smoother. We may uncover issues in OVN early. We will not get a broken gate if a change containing a bug is backported to OVN stable branch. At this point I can’t see any benefit of using the moving LTS branch, but if there is one please bring it up here. Any thoughts on this? Thanks, Kuba [1] https://opendev.org/openstack/neutron-specs/src/branch/master/specs/2025.2/… [2] https://review.opendev.org/c/openstack/neutron/+/961243

5 9

[kolla] Persistent `cannot fork child process` when launching any VM in all-in-one deployment
by Dennis Martin 13 Mar '26

13 Mar '26

Hi everyone, I've been debugging an issue for several weeks and have exhausted the obvious possibilities. I'm hoping the collective expertise here can point me in the right direction. ## Environment - **OpenStack**: Kolla-Ansible 2025.1 (Epoxy), all-in-one deployment - **OS**: Ubuntu 24.04 on a VM (nested virtualization) - **OKD target**: Trying to deploy OKD 4.18, but even a simple Cirros test VM fails ## The Problem Any attempt to create a VM (even `--image cirros --flavor m1.tiny`) fails with: ``` libvirt.libvirtError: cannot fork child process: Resource temporarily unavailable ``` The VM goes straight to `ERROR` state with no useful details in `nova-compute.log` beyond the same error. ## What Works ✅ - OpenStack services are up (`nova-compute`, `neutron`, etc. all healthy) - Can create networks, subnets, routers, keypairs via CLI - Direct `qemu-system-x86_64 -enable-kvm` test succeeds (KVM itself works) - `/dev/kvm` exists with correct permissions - KVM modules loaded (`kvm_intel`), nested virt enabled (`Y`) ## What We've Checked (All Fine) | Check | What We Found | Status | |-------|---------------|--------| | System PID limit (`pid_max`) | 4,194,304 | ✅ OK | | Kernel threads max (`threads-max`) | 722,077 | ✅ OK | | User process limit (`ulimit -u`) | 361,038 | ✅ OK | | Host thread count (`ps -eLf \| wc -l`) | ~111,000 | ✅ OK | | `nova_compute` container `pids.max` | 108,000 | ✅ OK | | `nova_compute` PIDs in container | 27 | ✅ OK | | `nova_libvirt` container `PidsLimit` | `<nil>` (unlimited) | ✅ OK | | AppArmor blocking libvirt | No profiles loaded | ✅ OK | | Host `libvirtd` running | Inactive | ✅ OK | | Libvirt log volume size | 12KB | ✅ OK | | RAM available | 88 GB total, plenty free | ✅ OK | | vCPUs | 32 cores | ✅ OK | ## What We Can't Check (Missing Commands) Inside the `nova_libvirt` container, the `ulimit` command is missing, so we cannot determine: - `nproc` limit inside the container - `nofile` (file descriptor) limit ## What We Haven't Checked - Kernel parameters like `vm.max_map_count` (default is 65530, could this be an issue?) - cgroup v2 limits on the `nova_libvirt` container (Ubuntu 24.04 uses cgroup v2) - `libvirtd` logs inside the container (the log file may not exist or be empty) ## The Ask Has anyone seen this in a Kolla-Ansible all-in-one deployment where all the obvious limits are large but libvirt still refuses to fork? Could it be: 1. A cgroup v2 limit we missed? 2. A kernel parameter that needs tuning (`vm.max_map_count`)? 3. Something else entirely? I'm happy to run any additional diagnostics or provide more logs. Any guidance would be hugely appreciated. Thanks, Dennis

2 1

[kolla-ansible][flamingo][vpnaas] Problem and solution
by Franck VEDEL (UGA) 13 Mar '26

13 Mar '26

2 3

Re: [Devel] OpenStack RPMs
by Neal Gompa 13 Mar '26

13 Mar '26

On Thu, Mar 12, 2026 at 8:08 PM Francesco Di Nucci via Devel <devel(a)lists.almalinux.org> wrote: > > Hi all, > > given that RDO will soon stop releasing RPMs of OpenStack, it has been > suggested on IRC etc that AlmaLinux and Rocky Linux communities might be > interested in building the RPMs instead, is there already a discussion > about it? > I think we'd generally prefer to see AlmaLinux contributors helping out in upstream RDO. If there are folks from the AlmaLinux community interested, please engage with RDO to help them. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

[kolla] Help debugging cannot fork child process when launching VMs in all-in-one deployment
by Dennis Martin 13 Mar '26

13 Mar '26

Hi Kolla team, I've been troubleshooting an issue for weeks and would really appreciate your insight. *Environment:* - Kolla-Ansible 2025.1 (Epoxy) all-in-one - Ubuntu 24.04 on VM (nested virtualization) - OpenStack services seem healthy (nova-compute, neutron, etc. all up) *The Problem:* Any attempt to create a VM (even a tiny Cirros test VM) fails with: text libvirt.libvirtError: cannot fork child process: Resource temporarily unavailable *What Works:* - ✅ Can create networks, subnets, routers, keypairs via CLI - ✅ Direct qemu-system-x86_64 -enable-kvm test succeeds - ✅ /dev/kvm exists with correct permissions - ✅ KVM modules loaded (kvm_intel), nested virt enabled (Y) *Resource Limits (all seem fine):* - RAM: 88 GB, vCPUs: 32 - pid_max: 4,194,304 - kernel.threads-max: 722,077 - ulimit -u: 361,038 - Total host threads: ~111k (well below limits) *Container-Specific Checks:* - nova_compute: pids.max=108k, Max processes=unlimited, only 27 PIDs running - nova_libvirt: No explicit PidsLimit (<nil>), logs not showing obvious errors - Libvirt volume only 12KB (no runaway logs) - Host libvirtd is inactive (no conflict) *What I've Tried:* - Recreated networks/routers multiple times - Restarted containers - Verified all endpoints are correctly set to VIP (192.168.58.50) - Checked kernel logs – no relevant errors *Full error from nova-compute log:* text libvirt.libvirtError: cannot fork child process: Resource temporarily unavailable Has anyone encountered this in an all-in-one deployment where all obvious limits are huge but libvirt still refuses to fork? Could it be a cgroup v2 limit I'm missing, or something in the libvirt container configuration? Any pointers would be hugely appreciated. Thanks, Dennis

1 0

[Keystone][ldap] Keystone bind request to ldap not able to interpret if the user's password is expired.
by Sharath Ck 12 Mar '26

12 Mar '26

Hi, I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set to true. However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed? Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response. P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked. user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true Regards, Sharath

3 3

[tc][ptls] OpenInfra Live: OpenStack 2026.1 'Gazpacho'
by Allison Price 12 Mar '26

12 Mar '26

Hi everyone, As we get closer to the next release date, I wanted to do the bi-annual call for volunteers to talk about the release highlights coming out of OpenStack 2026.1 ‘Gazpacho.’ The plan would be for this episode to be on Thursday, April 2 at 1400 UTC (9am CT). In case you have not seen a past episode, you can check out the format here [1]. If possible, I would like to finalize the lineup by first thing next week so we can promote with ample time. This is always our most popular webinar. If you have any questions, just let me know. Thanks! Allison [1] https://www.youtube.com/watch?v=cdqL6umlM1w

5 5

[dev][ptl][release] Cycle highlights for 2026.1/Gazpacho
by Jeremy Stanley 12 Mar '26

12 Mar '26

Now's the time for merging your 2026.1/Gazpacho release highlights, so if you have something you want to mention then write and push cycle-highlights additions for the corresponding deliverable files in the openstack/releases repository at your earliest opportunity. The OpenInfra marketing machine is getting ready to digest what's at https://releases.openstack.org/gazpacho/highlights.html and put together a press release and package for news outlets. They're interested in whatever you're excited to include, but especially anything related to AI, digital sovereignty, security, or VMware feature parity. Please get your highlights in this week if at all possible! -- Jeremy Stanley

1 1

Ideas to improve contributor and maintainer experience
by Ildiko Vancsa 10 Mar '26

10 Mar '26

Hi OpenStack Community, I’m reaching out to you about some next steps after the metrics and survey analysis for the Flamingo cycle. As we’ve been diving into data[1] and feedback[2] to better understand challenges that contributors and maintainers in OpenStack are facing, we reached the stage to start working with teams on improvement ideas. A few challenges stood out for us, like mismatched expectations caused by incomplete communication or silence, or inconsistencies in where maintainers track priorities and progress and where contributors look for this information. While more people to do reviews and maintenance work is always in need, clear and proactive communication practices can improve maintainer and contributor experience across the board. Below is a summary of the key ideas that Jeremy started to share with teams, to start experimenting with: 1. Make Review Priorities Explicit, and Don’t Forget to Keep Them Up to Date While many teams already document and publicize their review priorities and decision-making processes, the last survey round showed that contributors are often not aware of where to look for this information. Since there’s no single entry point into the community, mentioning the processes and pointing at resources is often helpful, like linking to priority criteria in review comments so contributors understand where their change fits and how they can engage in reprioritization discussions. Transparency here reduces uncertainty and helps contributors plan effectively. In addition, even when a team has a clear process to define, document and track priorities, information can get lost between release cycles. Adding it to the end-of-release tasks to update progress on ongoing items and deal with the ones that didn’t conclude in the cycle ending can improve contributor experience and help with more accurate planning for the upcoming cycle. This also means to check on the incomplete items at the start of the next release cycle and factor in that ongoing work when calculating bandwidth and availability. 2. Proactively Communicate Reviewer Availability It’s very easy to assume that project maintainers are available to do reviews full time, even more seasoned contributors make this mistake from time to time. Clear communication can ease the pressure on maintainers. This can include signals about reviewer bandwidth, upcoming absences, or looking for people who can take on ongoing reviews for some time can significantly reduce ambiguity. When contributors understand expected wait times—and are encouraged to share their own availability—coordination improves and stalled reviews can decrease. 3. Use Clear, Accessible Language Given that English is not the primary language for much of our community, we should avoid excessive acronyms and team-specific jargon. Clear, plain language lowers barriers to entry and reduces avoidable misunderstandings. It also helps new and casual contributors to feel more included and can increase the probability of them sticking around. 4. Develop Contributor and Reviewer Checklists Once the release cycle gets busy, it’s easy to forget about some of the above mentioned new practices before they become a habit. To help overcome that, we are also working on simple checklists to guide reviewers when leaving comments on new or in-progress changes. These will serve as lightweight guardrails for both new and experienced contributors and maintainers to further improve efficiency without added complication or burden. 5. Provide Reusable Review Templates Some of the above practices can result in broader comments in reviews, which can feel like a burden to reviewers and maintainers. We are working on creating response templates for common review scenarios, which you can fine tune for your project and context and then copy and paste into ongoing reviews where applicable. Templates can increase efficiency while reducing the time spent on phrasing review comments and making sure all useful information and resources are shared. Some teams have already been following this practice, which we will use as inspiration. You can also think about templates as a way to get through your review checklist quicker. 6. Publish Case Studies of Successful Contribution Models and Practices Some project teams seem to handle pressure and incoming load better than others, which can serve as inspiration for others to figure out what practices and methods to implement. This also applies to companies who have their employees working upstream, as in some having better practices to support their people than others. We aim to collaborate with teams and companies and teams alike to capture practices that yield better productivity without burnout. Documenting what works as case studies can help project teams and companies to understand how to implement practices in their own context. While we work on refining improvement ideas and sharing additional details we welcome your feedback and help to let us know what worked for you, and what practice didn’t produce the outcome or improvement you and your team hoped for. Some project teams are also experimenting with AI, to use it to speed up code reviews and navigate their tasks easier and more efficiently. While these practices are not yet ready to share widely as standards, OpenInfra community managers are curious to learn about your experience so far! We will schedule a session for the upcoming PTG[3] in April to discuss ideas and next steps further. Best regards, Ildikó [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://openinfra.org/ptg/

1 0

[openstack][neutron][ovn]Cannot ping VIP without disable port security
by Nguyễn Hữu Khôi 10 Mar '26

10 Mar '26

Hello, I am setting up HA OPNsense on OpenStack, and here are the steps I followed. I successfully configured CARP between two firewall instances, but from a PC in the same subnet as the VIP, I cannot ping the VIP address. When I capture traffic on the master firewall, I can see the ARP request and reply, but on my PC I do not see any reply packets. I have also configured allowed_address_pairs with the VIP address on the member ports, but the VIP only responds when I disable port security. Additionally, I created a port with the VIP address and assigned a floating IP to it. However, it does not work unless I *disable the port admin state*. When I repeatedly refresh the browser (press F5 many times), the traffic is redirected between the two firewall members, which means the connection does not remain persistent on the CARP master. Is there any additional configuration required in OpenStack (Neutron / OVN) to properly support CARP VIPs without disabling port security? Thank you for your assistance. Nguyen Huu Khoi

3 7

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 11 March
by Kees Meijs | Nefos 10 Mar '26

10 Mar '26

Hello Stackers, Tomorrow (that's 11 March) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0

[Nova][Vms]Persistent I/O Errors in RBD-backed Instances After Compute Node Failure
by Thamanna Farhath 10 Mar '26

10 Mar '26

Hello, We are currently investigating an issue related to OpenStack (2023.1) instances using Ceph RBD storage. However, after further testing in a lab environment we observed that the problem occurs specifically when a compute node goes down or reboots unexpectedly. In this situation, the instances that were running on the affected compute node later experience persistent I/O errors inside the guest OS, even after the compute node comes back online, the instance is usually in a SHUTOFF state, and when we try to start it again, the same I/O errors appear inside the guest. We also attempted instance evacuation to another compute node, but the evacuated instance still shows the same I/O errors inside the guest. We would like to understand the recommended approach in such cases: • What is the best practice to recover RBD-backed instances after a compute node failure when persistent I/O errors appear inside the guest? • Are there any recommended configurations or operational procedures in OpenStack or Ceph to prevent or mitigate this situation? Any suggestions or guidance would be greatly appreciated. Best regards, Thamanna Farhath Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

2 1

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

10 Mar '26

Hello Stackers, We're three weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. At the end of this week, all deliverables following the "cycle-with-rc" release model [2] will have published a release candidate. This should assist the community in testing, finding, and patching any release-critical issues for a timely release on April 01, 2026. Looking ahead into the 2026.2 "Hibiscus" release cycle, the OpenStack Technical Committee has updated testing runtimes [3]. We are strongly recommending testing all Python deliverables shipping in the Hibiscus release with Python 3.14; although the common CI template for unit testing will run the job as "non-voting". When we have an operating system available that ships Python 3.14 natively (such as the impending Ubuntu 26.04 LTS), test jobs are expected to become smoother and require less time and resources. PTL Elections are ongoing for Horizon and Barbican [4]. If you are an Active Project Contributor (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. I'd like to congratulate our latest Outreachy Intern, Rose Kimondo, for successfully completing her internship with the OpenStack Manila and Horizon project teams [5]. Rose worked on significant improvements to Manila UI, and Carlos Eduardo da Silva (carloss) and I had the pleasure of mentoring her. If you are aware of opportunities that would retain Rose in our community, please reach out directly to her. === Weekly Meeting === The TC has officially re-formed for the 2026.2 cycle, and our last weekly IRC meeting was held on March 03, 2026 [6]. Our immediate focus was establishing a steady administrative foundation. We'll be electing a new Chair, refreshing our liaisons for the Vulnerability Management, Election and DPL teams, and auditing our weekly meeting time to account for upcoming Daylight Saving Time changes in some parts of the world. Beyond these logistics, we discussed ongoing CI breakages in the requirements repository related to setuptools pinning and a particularly thorny issue where an abandoned dependency is currently blocking Horizon translations [7]. We also discussed "leaderless" project teams. For projects like Masakari, which shows promise in the current market conditions (such as VMware-to-OpenStack migrations), we are exploring a transition to the Distributed Project Leadership (DPL) model to spread the governance load among active contributors. Projects like Vitrage and Venus have seen prolonged inactivity without clear revival interest; we are moving toward their formal retirement. This serves our broader objective of directing community energy toward projects that demonstrate both active maintenance and clear future utility, rather than maintaining technical debt. The next meeting of the OpenStack Technical Committee is today, March 10, 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 [8]. I hope to see you there. === Upcoming Events === - 2026-03-10: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-03-12: 2026.1 "Gazpacho" Release Candidates due - 2026-03-23: KubeCon+CloudNativeCon EU begins: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 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) [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack release models: https://releases.openstack.org/reference/release_models.html [3] Tested runtimes for OpenStack 2026.2: https://governance.openstack.org/tc/reference/runtimes/2026.2.html [4] OpenStack 2026.2 PTL Elections: https://governance.openstack.org/election/ [5] Rose Kimondo's Outreachy Internship blog: https://rosekimondo.dev/blog/ [6] TC Meeting IRC Log, March 03 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-03-17.00.html [7] Horizon translations blocked: https://github.com/Zegocover/enmerkar/pull/8 [8] TC Meeting Agenda, March 10 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] Bug deputy - week of March 2nd
by Slawek Kaplonski 09 Mar '26

09 Mar '26

Hi, I was bug deputy last week. It was fairly quiet week regarding neutron bugs (there were issues impacting our CI but those were not really Neutron related). ### Critical - https://bugs.launchpad.net/neutron/+bug/2143144 - [networking-sfc] py312 job broken - fixed already by Rodolfo with: https://review.opendev.org/c/openstack/networking-sfc/+/978762 ### High - https://bugs.launchpad.net/neutron/+bug/2143336 - [FT] test_gateway_chassis_least_loaded_scheduler_anti_affinity unstable - **unassigned**, gate failure issue, for now we are skipping this unstable test ### Low - https://bugs.launchpad.net/neutron/+bug/2143050 - Auto allocate service plugin should inherit from ``neutron_lib.services.base.ServicePluginBase`` - fix proposed by Rodolfo: https://review.opendev.org/c/openstack/neutron/+/978898, - https://bugs.launchpad.net/neutron/+bug/2143233 - # [neutron-fwaas] Document: OVN driver has no ``logapi`` implementation - documentation improvement, I assigned it to myself, - https://bugs.launchpad.net/neutron/+bug/2143560 - # Optimization: create a bulk operation for ``_create_port_security_group_binding`` - unassigned, seems a bit like a low-hanging-fruit -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[puppet][tc] Future of the project
by Takashi Kajinami 09 Mar '26

09 Mar '26

I had similar discussions earlier in #puppet-openstack several times, but I think it's time to start more formal discussions. As some of you may know, Puppet OpenStack project has been facing several challenges for a few years due to the changes made in the external but related communities, and very honestly speaking, the project is at risk. IMO we have two major challenges now. - RDO officially announced that they discontinue RPM builds and focus on new container-base delivery, based on source-to-build. https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Because the primary (and only) architecture we currently support is installation from packages, this means CentOS Stream may no longer be in our support scope. CentOS Stream + RDO has been the primary (and only voting) test architecture because it provides the trunk packages which allow us to test the latest code in development. We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions) As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000 - The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676 So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days. I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle. Please reply to this in thread or reach me directly (in email or irc) if you are interested in further discussions. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

4 6

[keystone] App Credential reactivation after reconnection is not immediate
by Vincent Godin 08 Mar '26

08 Mar '26

If you create a 24-hour credential application with a non-local user who has a 2-hour time-to-live (default_authorization_ttl), after 2 hours the TTL resets to 0 and the credential application stops working, which is expected. If the user logs back in, there's a waiting period before the credential application becomes functional again, and the same applies if the user want to create a new credential application. I've noticed that if the user leaves a group with member privileges, for example, their app credentials are immediately invalidated. The same behavior should occur when the user logs back in after the TTL expires.

2 1

[Nova][vms]Preventing VM I/O Errors When Ceph OSD Nodes Go Down
by Thamanna Farhath 08 Mar '26

08 Mar '26

Dear Community, We are running OpenStack 2023.1 with Ceph as the backend storage on a 3-node deployment. Recently, we faced a scenario where two of our servers became unresponsive (hung state), and we had to reboot them. During this time, VMs running on the affected compute node started reporting I/O errors inside the guest OS, such as: [ 33.911093] blk_update_request: I/O error, dev vda, sector 229880 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 [ 33.914953] Buffer I/O error on dev vda1, logical block 319, lost async page write [ 33.914953] Buffer I/O error on dev vda1, logical block 320, lost async page write [ 33.927594] blk_update_request: I/O error, dev vda, sector 229904 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 It appears that when Ceph becomes unavailable (or quorum is lost), the VMs continue attempting writes, which results in I/O errors at the guest OS level. Our goal: We would like to prevent guest filesystem corruption or I/O errors when Ceph is down. Ideally, we want to: Pause or block writes from active VMs when Ceph storage is unavailable Avoid guest OS filesystem corruption Ensure safer recovery when Ceph services are restored Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 8

Re: Update on RDO: A Shift to Containers
by Jose Castro Leon 07 Mar '26

07 Mar '26

We are also heavily affected by this change, as all our deployments at CERN rely on it. Moreover, we are early adopters of RDO and now that we are getting into Epoxy release, it just slips away. The deployment model is not something you can easily change. Does it also mean that our el10 users may never have client libraries packaged to use our setups? And following Massimo remark, will the repo be maintained while it's still in supported status in OpenStack? If not, are you implying that we also need to repackage future security updates? Thanks, Jose CERN Cloud Team ________________________________ From: Massimo Sgaravatto <massimo.sgaravatto(a)gmail.com> Sent: Thursday, March 5, 2026 1:40 PM To: Amy Marrich <amy(a)demarco.com> Cc: RDO Developmen List <dev(a)lists.rdoproject.org>; openstack-discuss <openstack-discuss(a)lists.openstack.org>; users(a)lists.rdoproject.org <users(a)lists.rdoproject.org>; Mike Burns <mburns(a)redhat.com> Subject: Re: Update on RDO: A Shift to Containers A non-negligible impact for our deployment :-( So, as far as I understand, no rpms will be released for the F and G releases, correct? Will you keep releasing updated RPMs for the Epoxy release, while it is in the maintained status, or the repo https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ will not be updated anymore ? Thanks, Massimo On Wed, Mar 4, 2026 at 4:19 PM Amy Marrich <amy(a)demarco.com<mailto:amy@demarco.com>> wrote: Dear RDO Community/Stakeholders, This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered. End of RDO RPM Builds Historically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release. Introducing the New RDO: Container Focus The future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers. RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the <http://github.com/openstack-k8s-operators> github.com/openstack-k8s-operators<http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO". Timeline and Usage: * This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined. * These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization. * While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators. * Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform. Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward. Sincerely, Amy

4 3

[all] Another day another CI failure
by Brian Haley 07 Mar '26

07 Mar '26

Hi, Started seeing tox failures in pep8/docs/unit and some other jobs: AttributeError: 'Parsed' object has no attribute 'config_format' Melanie Witt provided some info at [0][1], I opened a bug [2] as it seems like it was caused by a recent commit. I would hold rechecks until someone confirms it's fixed. -Brian [0] https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-pep8&ski… [1] https://paste.opendev.org/show/bS87fFXvqOKODTRMllg4/ [2] https://github.com/tox-dev/tox/issues/3866

3 4

[release] Release countdown for week R-3
by Thierry Carrez 06 Mar '26

06 Mar '26

Development Focus ----------------- The Release Candidate (RC) deadline is next Thursday, March 12th, 2026. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2026.1 branch will be cut. This branch will track the 2026.1 "Gazpacho" release. Once stable/2026.1 has been created, the master branch will be ready to switch to 2026.2 "Hibiscus" development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2026.1 "Gazpacho" plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2026.1 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2026.1 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2026.2 "Hibiscus") to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2026.1 Gazpacho release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 12th, 2026 (R-3 week) 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 -- Thierry Carrez (ttx)

1 0

OpenStack RPMs
by Francesco Di Nucci 06 Mar '26

06 Mar '26

Hi all, given that RDO will soon stop releasing RPMs of OpenStack, it has been suggested on IRC etc that AlmaLinux and Rocky Linux communities might be interested in building the RPMs instead, is there already a discussion about it? Best regards Francesco Di Nucci -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

1 0

[kolla-ansible][flamingo][horizon] Network creation problem
by Franck VEDEL (UGA) 06 Mar '26

06 Mar '26

Hello everyone, I have a production OpenStack cluster for ESM students running Epoxy, deployed with Kolla-Ansible, and everything is working perfectly. I’m very satisfied with this setup. To prepare for upgrades, I set up a new test cluster in parallel using Kolla-Ansible, but this time with Flamingo. Everything seemed fine until I tried to create a network and its subnet in Horizon. The network is created, but no availability zone is associated with it. As a result, I cannot launch instances on this network. Could this be a change in the new OpenStack installation process that I missed? Or is this a bug? This is the first time I’ve encountered this issue. Is there a parameter that needs to be added in the Horizon override file (_9999-custom-settings.py) to handle this? Thanks in advance for any guidance. Franck VEDEL

2 1

testresources broken with latest fixtures
by Thomas Goirand 06 Mar '26

06 Mar '26

Hi, In its last version of fixtures, the tests folder has been move one directory up. Trying to rebuild testresources, it fails with: ERROR: unittest.loader._FailedTest.testresources.tests.test_test_resource ---------------------------------------------------------------------- ImportError: Failed to import test module: testresources.tests.test_test_resource Traceback (most recent call last): File "/usr/lib/python3.13/unittest/loader.py", line 396, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.13/unittest/loader.py", line 339, in _get_module_from_name __import__(name) ~~~~~~~~~~^^^^^^ File "/build/testresources-nCTnwj/testresources-2.0.2/testresources/tests/test_test_resource.py", line 18, in <module> from fixtures.tests.helpers import LoggingFixture ModuleNotFoundError: No module named 'fixtures.tests' This isn't seen downstream, as it's still possible to run latest versions of both fixtures and testresources, only testresources unit testing is broken with lastest fixtures, but I don't think it creates any issue for the users of these 2 libs. However, on the distro level, I'm not sure how to fix this... :/ Cheers, Thomas Goirand (zigo)

2 1

[neutron] multicast and allowed address pairs
by Bence Romsics 06 Mar '26

06 Mar '26

Hi Neutrinos, We have a user who discovered that two neutron backends behave differently when it comes to handling multicast traffic. This user runs servers that need multicast for VRRP coordination (the point is multicast, not VRRP). They discovered that with the (no longer upstream supported) OpenDaylight backend, they need to let the multicast traffic through with an allowed address pair. On the other hand, the ml2/ovs backend (here always assuming the ovs firewall driver) allows the multicast traffic by default. If you add the same allowed address pair (for example: {'mac_address': '01:00:5e:00:00:64', 'ip_address': '224.0.0.100'}) as with OpenDaylight, it actually breaks multicast traffic. The traffic breaks even on other servers, affected by the same set of flows installed by ovs-agent. My question is: which backend behaves correctly? And do we need to change anything upstream? Since I found the following upstream history... https://opendev.org/openstack/neutron/src/branch/master/doc/source/admin/co… https://bugs.launchpad.net/neutron/+bug/1889631 ... I believe that ml2/ovs (with the ovs fw driver) behaves correctly when it lets the multicast traffic through by default. However I believe it is a bug that the traffic breaks when the user adds the allowed address pair. But I think it would be pretty pointless to start fixing the traffic itself since we would need to make changes for no effect. Rather we could reject allowed address pairs with multicast IPs/MAC addresses, because that would call the attention of the user that multicast traffic is already handled at a different place (that is the default behavior of the fw driver). I also believe that the OpenDaylight driver is buggy when it does not let the multicast traffic through just like ml2/ovs does. However this is not an upstream problem anymore, since networking-odl is long deprecated. Do you agree in the judgement where the bugs are in this case? The possible upstream change: Do you think we should start rejecting allowed address pairs with multicast IPs/MAC addresses? Plus I guess a doc update for allowed address pairs api-ref is due... If needed, I'm happy to bring this to the drivers meeting. It's 100% that I could attend next Friday (6th of March) and 80% for this Friday (27th of February). Thanks, Bence

3 3

[cinder] festival of reviews friday 2026-03-06
by Brian Rosmaita 06 Mar '26

06 Mar '26

Hello Argonauts, It's the first week of March, which means that the twice monthly Cinder Festival of Reviews will be held at the end of this week on Friday 6 March. who: Everyone! what: The Cinder Festival of Reviews when: Friday 6 March 2026 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

Update on RDO: A Shift to Containers
by Amy Marrich 05 Mar '26

05 Mar '26

*Dear RDO Community/Stakeholders,This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered.End of RDO RPM BuildsHistorically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release.Introducing the New RDO: Container FocusThe future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers.RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the github.com/openstack-k8s-operators <http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO".Timeline and Usage: - This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined.- These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization.- While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators.- Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform.Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward.Sincerely,* Amy

2 1

[Nova][Tacker][Issue Investigation] API Schema Inconsistency in Nova Microversion 2.100 - Impacting Tacker CI Jobs
by Shivam Shukla 05 Mar '26

05 Mar '26

Hi Nova Team, We are currently facing an issue in Tacker (master branch) caused by a bug in Nova microversion 2.100, where scheduler_hints.group is returned as a list instead of a string in the server GET API response. Problem Statement: The server GET API (microversion 2.100) returns scheduler_hints.group as a list, whereas the API schema requires it to be a string UUID. This type mismatch causes server rebuild operations to fail with a 400 Bad Request error. Root Cause: Nova stores scheduler hints internally using DictOfListOfStringsField, so all values are kept as lists. When microversion 2.100 exposes scheduler hints in the API response, the group field is returned in its raw internal form without being converted back to the string format required by the API spec. Impact: This bug is causing test case failures in Tacker CI jobs, making our pipeline unstable. Detailed information about the bug can be found in the reports linked below: Nova Bug: https://bugs.launchpad.net/nova/+bug/2139275 We'd appreciate your help in reviewing and fixing this bug at the earliest, as it is actively impacting Tacker CI stability. Please let us know if you need any additional details from our side. Thanks in advance for your support! Thanks & Regards, Shivam Shukla (シヴァム・シュクラ) Mobile: +91-9450053922 E-mail: shivam.shukla3(a)india.nec.com The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC Corporation India Private Limited or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC Corporation India Private Limited or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

1 0

[requirements][horizon] Requirements freeze exception for XStatic-Font-Awesome
by Tatiana Ovchinnikova 05 Mar '26

05 Mar '26

Hello, I would like to request a requirements freeze exception to unpin XStatic-Font-Awesome and bump it from 4.7.0.0 to 6.2.1.2 [1]. This version doesn't use pkg_resources in build. From Horizon side we have worked around the required changes to use newer versions of the font [2], and after the requirements upgrade to 6.2 the hack can be safely removed. With kind regards, Tatiana [1] 977626: Bump XStatic-Font-Awesome to 6.2.1.2 and unpin it | https://review.opendev.org/c/openstack/requirements/+/977626 [2] 977249: A hack to make Horizon work with Font Awesome 6.2 | https://review.opendev.org/c/openstack/horizon/+/977249

2 1

[requirements][horizon] Requirements freeze exception for selenium
by Tatiana Ovchinnikova 05 Mar '26

05 Mar '26

Hello, I would like to request a requirements freeze exception to unpin Selenium and bump it from 3.141.0 to 4.41.0 [1]. Selenium 3.141.0 no longer works with modern urllib3. It needs to be updated to ensure compatibility with other libraries like urllib3. All required work has been done from Horizon side [2]. As a temporary workaround local upper-constraints.txt was created [3], and the follow up patch to remove it and roll back to global requirements is prepared [4]. With kind regards, Tatiana [1] 978157: Unpin selenium and use latest | https://review.opendev.org/c/openstack/requirements/+/978157 [2] 978177: Upgrade selenium to 4.41.0 | https://review.opendev.org/c/openstack/horizon/+/978177 [3] 978078: Create and use local upper-constraints to avoid Selenium failing | https://review.opendev.org/c/openstack/horizon/+/978078 [4] 978896: Remove local upper-constraints and go back to global one | https://review.opendev.org/c/openstack/horizon/+/978896

2 1

[requirements][sdk] Requirements freeze exception for 'testtools'
by Stephen Finucane 05 Mar '26

05 Mar '26

o/ I would like to request a requirements freeze exception to bump `testtools` from 2.8.4 to 2.8.5, as proposed here [1]. testtools 2.8.5 includes a small type hint fix [2] that resolves pep8 failures currently seen in the gates of a number of SDK deliverables [3][4][5]. It carries effectively zero risk and bumping it would be both easier and safer than updating the affected projects across both master and stable/2026.1 to add `type: ignore` comments or disable the check. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/978329 [2] https://github.com/testing-cabal/testtools/compare/2.8.4...2.8.5 [3] https://review.opendev.org/c/openstack/osc-lib/+/978668 [4] https://review.opendev.org/c/openstack/cliff/+/978659 [5] https://review.opendev.org/c/openstack/python-openstackclient/+/978670

2 1

[requirements][sdk] Requirements freeze exception for 'fixtures'
by Stephen Finucane 05 Mar '26

05 Mar '26

o/ I would like to request a requirements freeze exception to bump `fixtures` from 4.3.0 to 4.3.1, as proposed here [1]. As with my earlier testtools request, fixtures 4.3.1 includes a small type hint fix [2] that resolves pep8 failures currently seen in the gates of a number of SDK deliverables. Once again, the bump carries effectively zero risk and bumping it would be both easier and safer than updating the affected projects across both master and stable/2026.1 to add `type: ignore` comments or disable the check. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/978871 [2] https://github.com/testing-cabal/fixtures/compare/4.3.0...4.3.1

2 1

[CloudKitty] Core Reviewer Nominations of Juan Larriba and Jaromir Wysogla
by Rafael Weingärtner 04 Mar '26

04 Mar '26

Hello team, I am writing to nominate Juan Larriba (<jlarriba(a)redhat.com>) and Jaromir Wysogla (<jwysogla(a)redhat.com>) as core reviewers for the CloudKitty project. Over the past months they have made significant contributions to the project. We have discussed their nomination in the last bi-weekly meeting, and we will move on with the addition. -- Rafael Weingärtner

1 0

[election][barbican] PTL Candidacy for the 2026.2 Release Cycle
by Mauricio Harley 04 Mar '26

04 Mar '26

Hi, everyone. I would like to continue serving as PTL for Barbican during the 2026.2 cycle. Over the past cycle, I worked to keep the project healthy and aligned with OpenStack's evolving standards. Key achievements include dropping the unmaintained repoze.profile dependency, adopting oslo.middleware's common RequestId implementation, fixing CI nodeset configurations for the Dogtag functional tests, and maintaining release notes across stable branches. I have also ensured alignment with upstream tooling and supported ongoing maintenance across barbican-ui, barbican-tempest-plugin, and openstack-ansible-os_barbican. As the current PTL, I am familiar with the project's codebase, its integration points with other OpenStack services, and our operator community's needs. I am committed to continuing this work, ensuring Barbican remains a reliable secrets management solution, and fostering collaboration with contributors and downstream consumers. I respectfully ask for your support in the upcoming election. Maurício Harley (mharley)

2 1

[neutron][OVN] North South wont work
by Nguyễn Hữu Khôi 04 Mar '26

04 Mar '26

Hello, I have the following issue: My router has an external interface and an internal interface. An instance can ping the router’s external interface, but it cannot ping the external provider network gateway. I am using distributed floating IPs. I created another router using the same provider network, and instances connected to that router can reach the external gateway without any issues. Could you please suggest how I can debug this problem? Openstack Env: 2025.1 Thank you. Regards Nguyen Huu Khoi

2 5

[OSSA-2026-003] OpenStack Vitrage: Remote code execution through Vitrage query parser (CVE-2026-28370)
by Jeremy Stanley 04 Mar '26

04 Mar '26

================================================================= OSSA-2026-003: Remote code execution through Vitrage query parser ================================================================= :Date: March 03, 2026 :CVE: CVE-2026-28370 Affects ~~~~~~~ - Vitrage: <12.0.1, ==13.0.0, ==14.0.0, ==15.0.0 Description ~~~~~~~~~~~ Khalil Lemtaffah (Nokia) reported a vulnerability in the Vitrage query parser. A user allowed to access the Vitrage API may trigger code execution on the Vitrage service host as the user the Vitrage service runs under. This may result in unauthorized access to the host and further compromise of the Vitrage service. All deployments exposing the Vitrage API are affected. Patches ~~~~~~~ - https://review.opendev.org/962671 (2023.1/antelope) - https://review.opendev.org/962713 (2024.1/caracal) - https://review.opendev.org/962712 (2024.2/dalmatian) - https://review.opendev.org/962646 (2025.1/epoxy) - https://review.opendev.org/962658 (2025.2/flamingo) - https://review.opendev.org/962617 (2026.1/gazpacho) Credits ~~~~~~~ - Khalil Lemtaffah from Nokia (CVE-2026-28370) References ~~~~~~~~~~ - https://storyboard.openstack.org/#!/story/2011539 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-28370 Notes ~~~~~ - The stable/2023.1 branch is unmaintained and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

[manila] Requesting a feature freeze exception for adding Resource Locks in the Manila UI
by Rose Kimondo 03 Mar '26

03 Mar '26

Hi Carlos and Goutham, I would like to formally request a feature freeze exception for the Resource Locks panel for it to be included in this release cycle. My Outreachy internship ends on Friday this week (Match 6th) and I would like to wrap up majority of my work. I would also like to note that adding this feature does not bump the manila API microversion or any add new requirements to the manila-ui project Kind Regards, Rose Kimondo.

3 2

[Nova][vms]Preventing VM I/O Errors When Ceph OSD Nodes Go Down
by Thamanna Farhath 03 Mar '26

03 Mar '26

Dear Community, We are running OpenStack 2023.1 with a 3-node Ceph cluster. Recently, one Ceph nodes became unresponsive, resulting in quorum loss., VMs experienced I/O errors as expected. [ 33.911093] blk_update_request: I/O error, dev vda, sector 229880 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 [ 33.914953] Buffer I/O error on dev vda1, logical block 319, lost async page write [ 33.914953] Buffer I/O error on dev vda1, logical block 320, lost async page write [ 33.927594] blk_update_request: I/O error, dev vda, sector 229904 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 We understand this behavior is by design and that Nova does not automatically act based on Ceph health. However, our concern is recovery. In some cases, simply rebooting the VM is not sufficient, and I/O errors persist even after Ceph regains quorum. What is the recommended best practice to safely recover RBD-backed instances in such scenarios? How can we retrieve and restore affected VMs while minimizing filesystem corruption? Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

April 2026 PTG Team List Announcement
by Kendall Nelson 03 Mar '26

03 Mar '26

Hello Everyone! The April 2026 Project Teams List is official! If your team was planning to meet and isn’t in the list below, please contact ptg(a)openinfra.org IMMEDIATELY. Projects + Teams - OpenInfra Project Teams - Inclusivity WG - Kata Containers - StarlingX - - OpenStack - Services - Blazar - Cinder - Cloudkitty - Cyborg - Designate - Glance - Horizon - Ironic - Keystone - Kolla - Manila - Masakari - Neutron - Nova - Octavia - OpenStack-Ansible - OpenStack-Helm - Tacker - Telemetry - Watcher - Other OpenStack Teams - openstack-i18n - Technical Committee - Adjacent Communities - Yaook <- First time attending a PTG! Welcome! Soon I will be contacting moderators to sign up for time via the PTGBot[1] once it is configured to begin scheduling meeting times. In the meantime, please register if you haven't done so already and encourage your teams to do so as well[2]. As usual, feel free to let us know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://opendev.org/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: https://ptg.openinfra.org/

1 0

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

03 Mar '26

Hello Stackers, We're four weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. We're past feature freeze at this point, and project teams are expected to be busy finding and fixing bugs in order to ship our first release candidates in the next couple of weeks. In the past week, five seats on the OpenStack Technical Committee were renewed [2]. I'd like to thank Artem Goncharov (gtema) for the years he spent on the TC. He brought unique perspectives as the PTL of several projects. I'd also like to congratulate Amy Marrich (spotz), Dmitriy Robotyegov (noonedeadpunk), and Dan Smith (dansmith) for being re-elected to the TC. Elections are underway for new PTLs for the Barbican and Horizon project teams. No new governance proposals were merged in the last week. As we wrap up this release cycle, the TC's focus will switch to ensuring a smooth transition between project leaders, filling vacant governance positions within projects, renewing liaisons for cross-project work, and finalizing the tested runtimes for the upcoming release cycle [3]. === Weekly Meeting === The last meeting of the OpenStack Technical Committee was hosted on February 24, 2026, in the #openstack-tc channel on OFTC [4]. We had a candid discussion regarding the size of the TC relative to the community; while there is an argument for shrinking the committee to match candidate interest, our stance is that our workload remains high, and a smaller group would struggle to maintain the necessary oversight without burning out. We took a moment to thank gtema as he ends his term; his expertise in Keystone and the OpenStack SDK has been invaluable, and while he is stepping down from the TC, his "healthy frustration" with bureaucracy will no doubt continue to drive improvements across the projects he leads. We then began our work on stabilizing "leaderless" teams. We noted that Oslo requires a dedicated release liaison to keep our foundational libraries moving. We are hoping that more individuals from the core maintainer team for Oslo participate in the project's formal governance. We discussed a PTL nomination that was blocked due to contribution requirements. The committee seemed supportive of changing how we define contribution. We are going to explore a TC charter change to grant Active Contributor (AC) status to consistent reviewers (+2/+3), recognizing that the "unseen" work of code review is just as vital to project health as code changes themselves. Regarding the gate, a massive update to upper-constraints merged this week, touching over 140 non-OpenStack dependencies. Across project teams, the immediate priority was "de-borking" stable branches due to these changes and monitoring for regressions on the "master" branches to ensure the 2026.1 release remains stable. The next meeting of the OpenStack Technical Committee is today, March 3, 2026. This meeting will be hosted in the #openstack-tc IRC channel on OFTC. Please find the agenda on the meeting's wiki page [5]. I hope to see you there. === Upcoming Events === - 2026-03-10: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-03-12: 2026.1 "Gazpacho" Release Candidates due - 2026-03-23: KubeCon+Cloud Native Con EU begins: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2026-04-20: OpenInfra PTG begins: https://openinfra.org/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack TC: https://governance.openstack.org/tc/#current-members [3] Tested runtimes for 2026.2: https://review.opendev.org/c/openstack/governance/+/976691 [4] TC Meeting IRC Log, February 24, 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-24-17.00.html [5] TC Meeting Agenda, March 03, 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on February 27, 2026
by Ildiko Vancsa 03 Mar '26

03 Mar '26

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __February 27th, 2026 at 1300UTC,__ which is this Friday! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. We have a packed agenda for this call: - OpenStack HA architectures with guest attendee Tyler Stachecki - How to do OpenStack Backups? - How do people automate their clouds? - Update on Ops Radio Hour Survey results If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> <https://matrix.to/#/%23openstack-ops:opendev.org%3Chttps://matrix.to/%23/%2…> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on February 27th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[neutron] Bug deputy report (week starting on February 23)
by Elvira Garcia Ruiz 02 Mar '26

02 Mar '26

Hi folks! Here is the list of bugs reported for Neutron last week. Most of this week's higher-priority changes are related to FT and Tempest. Critical ---------- - https://bugs.launchpad.net/neutron/+bug/2142679 test_dns_integration fails with testtools 2.8+ due to removed try_import Fix proposed and merged by Rodolfo: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/977958 High ------- - https://bugs.launchpad.net/neutron/+bug/2142487 [FT] `test_patch_port_ofport` test unstable Unassigned - https://bugs.launchpad.net/neutron/+bug/2142484 [FT] `test_bgp_extension_missing_bgp_peer_bridges` test unstable Unassigned - https://bugs.launchpad.net/neutron/+bug/2142659 [whitebox-neutron-tempest-plugin] Errors when executing the unit tests locally Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/977946 - https://bugs.launchpad.net/neutron/+bug/2142669 [OVN] ML2/OVN is missing ``ip_allocation`` extension Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/977961 Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2142846 [neutron-fwaas] The "firewall_drivers" entry point should also have "ovn" defined Unassigned Low ------ - https://bugs.launchpad.net/neutron/+bug/2142652 Define a reasonable default value for the OVN FDB aging and removal limit Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/977984 - https://bugs.launchpad.net/neutron/+bug/2142833 Lack of consistency in the log messages for the OVN maintenance methods Unassigned - https://bugs.launchpad.net/neutron/+bug/2142834 Improve `check_global_dhcp_opts` method Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/978182 - bugs.launchpad.net/neutron/+bug/2142840 Method ``network_segments_exist_in_range`` to use a specific SQL query Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/978187 Best regards! Elvira

1 0