- openstack-discuss - lists.openstack.org

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

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

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][Manila][Feature Freeze Exception require for NetApp driver NAE feature
by Gireesh Awasthi 27 Feb '26

27 Feb '26

Hi Carloss and Goutham, As we approach the feature freeze for the OpenStack Gazpacho release, I would like to formally request an exception to include the NAE (NetApp Aggregate Encryption) feature in this release cycle. NAE is an important feature of the NetApp Manila driver, and a significant number of customers are eagerly awaiting for it. Regards, Gireesh

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

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

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

1 0

[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][tc] Combined PTL/TC 2026.2 cycle Election Nominations End
by Ian Y. Choi 26 Feb '26

26 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…

2 1

[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