- openstack-discuss - lists.openstack.org

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

27 Feb '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 2

[release] Release countdown for week R-4, Mar 02 - 06
by Elõd Illés 27 Feb '26

27 Feb '26

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2026.1 Gazpacho deliverables can be proposed, well ahead of the final 2026.1 Gazpacho release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2026.1 Gazpacho release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2026.1 Gazpacho, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2026.1 Gazpacho that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By March 26th, 2026 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2026.1 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2026.1 Gazpacho changes should be added there to make sure the consumers of your release notes see them. 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 Előd Illés irc: elodilles @ #openstack-release

1 0

[dev][nova] Suspected inconsistency in cleanup of failed batch schedule
by Dominik Danelski 27 Feb '26

27 Feb '26

Hello everyone, TL;DR If one of the batch-scheduled instances fails at the manager level, do we want all other to fail and be cleaned or only the one causing the issue? Background: When implementing a fix that would delete Placement allocations for VMs that were never correctly scheduled (https://review.opendev.org/c/openstack/nova/+/968446) a reviewer correctly recognised that _cleanup_build_artifacts that further calls my cleaning function is itself called 3 times (all in schedule_and_build_instances): 1. When dealing with going over quota on recheck – that's my interest and it happens before dispatching the build requests to the computes 2 and 3. during schedule loop where an exception causes running _cleanup_build_artifacts after some instances may have been sent to be built on compute using build_and_run_instance The issue comes from the fact that in all cases _cleanup_build_artifacts is provided with the list of ALL scheduled instances, not just the failing one, so any of its effects may be performed on already scheduled instances, if it was called from case 2 or 3. Then, what version is correct? Do we want all instances to fail and be cleaned in bulk schedule when at least one of them failed, or do we want to gracefully handle the failing one and proceed with as many of the rest as we can? Version 1 seems to be the intended cause of events, as this was the first use of the cleanup function which was further borrowed by other authors in later patches. The code as is is inconsistent with both versions: we don't cancel and clean instances after one of them fails, since by that time we have already created a side-effect of sending them to computes (cases 2 and 3). We are also not consistent with the 'graceful failure' case, as in all 3 cases we send all instances to the cleanup function which, among other things, sets the ERROR state on them. I definitely plan to create a patch straightening things out, as it is the blocker for the bug fix I try to introduce to the cleanup function, but I need to know in what direction to proceed: prevent instances from being built until we have confirmed that all of them passed the checks which could trigger the cleanup OR leave the current dispatch flow as is, but only call cleanup on failing instances. With or without my patch, I believe the current code is internally inconsistent. Unfortunately, the cleanup function does not have its docstring and I couldn't find any comment on which behaviour is the expected one. Kind regards Dominik Danelski

2 2

[horizon][requirements] Upgrade of urllib breaks Selenium
by Radomir Dopieralski 27 Feb '26

27 Feb '26

Hello everyone, we have just recently fixed our gates in the Horizon project from the pkg_resources, but we noticed just now that they broke again, this time because urllib was upgraded in the global requirements: https://review.opendev.org/c/openstack/requirements/+/972462 Unfortunately, it seems that this version of urllib doesn't work with the version of selenium library that is forced by the global requirements. And naturally that makes all our integration tests fail. As a temporary measure we are going to use a local copy of the global constraints file with the urllib downgraded for the selenium jobs, just to unblock the gates. This is a very sensitive time for us, because we have to cut a release very soon. We will try to find a better solution for the long term. Suggestions welcome. Regards,

3 6

[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 26 Feb '26

26 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 25 Feb '26

25 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