- openstack-discuss - lists.openstack.org

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

02 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 4

[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

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

02 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

2 3

[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

4 3

[manila] 2026.1 Gazpacho bugsquash - Mar 2nd - 5th
by Carlos Silva 27 Feb '26

27 Feb '26

Hello, zorillas and interested stackers. The 2026.1 Gazpacho bug squash is happening next week and we will be focusing on closing in-progress bugs and reviews. Vida (vhari) worked on the bugsquash etherpad [1]. In case you'd like to work on a bug that is not on the list, please add it. The kick-off meeting will happen on March 2nd at 1500 UTC on meetpad [2] and the March 5th manila weekly meeting slot will be used for the bugsquash. In case you intend to participate, please add the meeting's .ics file [3] to the calendar of your preference. Looking forward to it! [1] https://etherpad.opendev.org/p/manila-gazpacho-bugsquash [2] https://meetpad.opendev.org/p/manila-gazpacho-bugsquash [3] https://gist.github.com/silvacarloss/9ad40610c78655dba3dd5ed256c6b978 Regards, carloss

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

2 1

[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

[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