- openstack-discuss - lists.openstack.org

[all][elections][tc] 2026.2 Hibiscus Technical Committee Election Results
by Ian Y. Choi 27 Feb '26

27 Feb '26

Please join me in congratulating the 5 newly elected members of the Technical Committe (TC). - Amy Marrich (spotz) - Dan Smith (dansmith) - Goutham Pacha Ravi (gouthamr) - Michal Nasiadka (mnasiadka) - Dmitriy Rabotyagov (noonedeadpunk) Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round.

2 1

OpenStack Ops Radio Hour Survey - Timing, cadence and more
by Ildiko Vancsa 27 Feb '26

27 Feb '26

Hi All, I’m reaching out to you to draw your attention to the new OpenStack Ops Radio Hour Survey! As a reminder, the OpenStack Ops Radio Hour gathering is a meeting series in a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. The group organizers put together a survey to better understand what channels people use to learn about upcoming meetings, what topics they would be interested in discussing, and what timing and cadence would be most suitable for folks onwards. You can find the survey here: https://openinfrafoundation.formstack.com/forms/openstack_ops_radio_hour_su… Your input is very important to make the gatherings as widely available and inclusive as possible! Please fill out the survey __by February 25, 2026.__ In the meantime, the next Ops Radio Hour is scheduled to happen on February 27th, 2026 at 1300UTC. You can find more information, agenda items and notes and recordings from previous meetings here: https://etherpad.opendev.org/p/openstack_ops_radiohour Please let me know if you have any questions or run into any challenges with the survey. Thanks and Best Regards, Ildikó

1 2

[all][elections][ptl] PTL 2026.2 cycle Election Voting Kickoff
by Ian Y. Choi 26 Feb '26

26 Feb '26

Polls for PTL elections are now open and will remain open for you to cast your vote until Mar 18, 2026 23:45 UTC. We are having elections for Barbican, Horizon. If you are a Foundation individual member and had a commit in one of the team's deliverable repositories[0] over the Mar 14, 2025 00:00 UTC - Feb 18, 2026 00:00 UTC timeframe (2025.2 to 2026.1) then you are eligible to vote. You should find your email with a link to the Condorcet Internet Voting Service (CIVS) page to cast your vote in the inbox of your Gerrit preferred email[1]. What to do if you don't see the email and have a commit in at least one of the projects having an election: * due to a new CIVS policy, to get the email from poll supervisors, you must opt in to email communication opt in with your Gerrit email address at: https://civs1.civs.us/cgi-bin/opt_in.pl * eligible voters who opt in to email communication late can see a pending poll invitation and vote until Mar 18, 2026 23:45 UTC. * check the trash or spam folders of your Gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the project's deliverable repos[0] and email the election officials. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/#ptl-candidates Happy voting, [0] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [1] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent.

1 0

[all] client functional jobs are broken by new tox release
by Takashi Kajinami 25 Feb '26

25 Feb '26

Hi, Another fun moment :-) New tox 4.46.0 was released quite recently. This release requires virtualenv 20.39.0 which was released a few days ago (See https://github.com/tox-dev/tox/issues/3069 for details). This conflict with virtualenv pinned to 20.38.0 in upper-constraints and we found some of the functional jobs of client libs (at the moment of writing, cinderclient and heatclient at least) due to the following behavior. - These jobs first install devstack and run tox to test clients accessing API - tox in current CI image is <4.46.0, but it is updated to 4.46.0 due to somehow neutron plugin installs tox (it loos like this is not actually required and I'm trying to get rid of it by https://review.opendev.org/c/openstack/devstack/+/977970 ) - however virtualenv is still pinned to 20.38.0 due to uc. The typical error caused by this combination is "AttributeError: 'PythonSpec' object has no attribute 'machine'" # See https://zuul.opendev.org/t/openstack/build/3f2448194352452a9f674d6c0648b816 There is still some discussions about whether we can bump virtualenv in u-c[2]. Please be aware of this and avoid recheck for now. [2] https://review.opendev.org/c/openstack/requirements/+/977947 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 1

using postgresql in production
by Jiatong Shen 25 Feb '26

25 Feb '26

Hello community, We are analyzing the possibility of using PostgreSQL in production. The reason behind is that the PostgreSQL community is very open and growing fast, besides many Chinese companies provide PG compatibility. My question is what are the pros and cons between using PG and MariaDB. Are there any tools available to do online data migration for legacy environments? Any insight is deeply appreciated. Thank you. -- Best Regards, Jiatong Shen

7 8

[openstack-helm] Removing support for tungstenfabric in neutron and nova charts
by Mathieu Gagné 24 Feb '26

24 Feb '26

Hi, It appears tungstenfabric is no longer active. [1] > The official Tungsten Fabric website states that the project will be shut down on August 1, 2024. The latest images consumed by openstack-helm [2][3] found on Docker Hub are from 5 years ago for nightly [4] and 8 years for non-nightly [5]. Considering the state of the tungstenfabric project, the plan is to remove support from openstack-helm. [6] If there are any objections, please let them know. [1] https://codilime.com/blog/tungsten-fabric-closing/ [2] https://opendev.org/openstack/openstack-helm/src/branch/master/values_overr… [3] https://opendev.org/openstack/openstack-helm/src/branch/master/values_overr… [4] https://hub.docker.com/u/opencontrailnightly [5] https://hub.docker.com/u/opencontrail [6] https://review.opendev.org/c/openstack/openstack-helm/+/977852 -- Mathieu

2 1

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 25 February
by Kees Meijs | Nefos 24 Feb '26

24 Feb '26

Hello Stackers, Tomorrow (that's 25 February) 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 I'm not able to make the meeting myself this time, but feel free to discuss whatever is on the table. See you next time! 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

[release][horizon][ironic] cycle-with-intermediary deliverables without any release yet in 2026.1 Gazpacho
by Elõd Illés 23 Feb '26

23 Feb '26

Hi, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the 2026.1 Gazpacho cycle: [horizon] horizon [ironic] bifrost ironic-ui networking-baremetal networking-generic-switch Those should be released ASAP, and in all cases before March 12th, 2026, so that we have a release to include in the final 2026.1 Gazpacho release. Előd Illés irc: elodilles @ #openstack-release

1 0

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

23 Feb '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.

1 0

[neutron] multicast and allowed address pairs
by Bence Romsics 23 Feb '26

23 Feb '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

1 0