- 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 01 Mar '26

01 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

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

26 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

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

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

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

25 Feb '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."

3 2

using postgresql in production
by Jiatong Shen 24 Feb '26

24 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

[neutron] Bug deputy report (week starting on February 16)
by Bernard Cafarelli 23 Feb '26

23 Feb '26

Hey neutrinos, here is the list of bugs reported last week. Mostly quiet on the new bugs count, though oslo.service 4.5.0 kept the team busy! Critical * Neutron periodic and maintenance worker broken, oslo.service 4.5.0 - https://bugs.launchpad.net/neutron/+bug/2142122 Subject says it all, neutron test for oslo.service at https://review.opendev.org/c/openstack/neutron/+/977242 High * neutron-fwaas unit tests are failing with: oslo_config.cfg.DuplicateOptError: duplicate option: router_distributed - https://bugs.launchpad.net/neutron/+bug/2141942 FWaaS UT failure, fixed by merged https://review.opendev.org/c/openstack/neutron-fwaas/+/975752 Medium * Any ML2 plugin should support "filter-validation" extension - https://bugs.launchpad.net/neutron/+bug/2142034 Found with FWaaS plugin, unassigned Low * DbQuotaNoLockDriver cannot be spawned by oslo_service, defaults to fork - https://bugs.launchpad.net/neutron/+bug/2142222 New warning from oslo.service 4.5.0, unassigned RFE * Preset options to configure the OVN BFD values - https://bugs.launchpad.net/neutron/+bug/2142096 WIP implementation at https://review.opendev.org/c/openstack/neutron/+/977209 Regards, -- Bernard Cafarelli

1 0

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

22 Feb '26

Hello Stackers, We're five weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. On Thursday this week, we'll observe a feature freeze across all deliverables following a cycle-with-rc release model [2]. This is in preparation for the first release candidate for all these deliverables in a couple of weeks. During this past week, CI was unstable due to upstream changes, and a lot of it required work from across project teams. We're hoping that the testing remains uneventful while we go through this last leg of our release journey. The OpenStack Technical Committee did not make any new governance changes in the past week. We're defining the tested runtimes for the OpenStack 2026.2 "Hibiscus" release cycle [3]. Please take a look and give us your feedback. === Weekly Meeting === The last weekly meeting of the OpenStack TC occurred on February 17, 2026, over the #openstack-tc channel on OFTC [4]. We discussed the ongoing election cycle. A lot of the PTL and TC nominations were pending at the time of this meeting, and we were proactively considering next steps. As is usual, however, we expect (and saw) a late surge of nominations before the deadline. On the technical front, we are intensifying our focus on the Requirements team's health and its integration with deployment-focused contributors. The current lack of a confirmed Deployment Project Liaison (DPL) team risks pushing us into a TC appointment stage, which we would prefer to avoid through active community engagement. We're hoping to make the global requirements process more accessible to downstream owners and deployment experts to ensure our dependency management reflects real-world production needs. Finally, we noted several ongoing CI issues. While the setuptools regressions have stabilized significantly on the master branch, we have targeted work remaining to ensure that older supported stable branches have a viable CI. The next meeting of the OpenStack TC is on Tuesday, February 24, 2026. This meeting will be held at 1700 UTC, over IRC in the #openstack-tc channel on OFTC. Please find the meeting's agenda on the meeting's wiki page [5]. Please feel free to edit the ping list and add your nickname if you'd like to be alerted during the meeting. === Governance Proposals === ==== Open For Review ==== - Restore DPL model for requirements project | https://review.opendev.org/c/openstack/governance/+/977547 - Define testing runtime for 2026.2 release | https://review.opendev.org/c/openstack/governance/+/976691 - Revert "Revive os_monasca" | https://review.opendev.org/c/openstack/governance/+/974775 - Appoint Arnaud Morin as PTL for mistral | https://review.opendev.org/c/openstack/governance/+/977344 === Upcoming Events === - 2026-02-26: 2026.1 "Gazpacho" Feature Freeze / Milestone 3 - 2026-03-10: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-03-23: KubeCon + CloudNativeCon Europe 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) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] Cycle with RC release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc [3] Tested runtimes for 2026.2: https://review.opendev.org/c/openstack/governance/+/976691 [4] TC Meeting IRC Log, February 17, 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-17-08.00.html [5] TC Meeting Agenda, February 24, 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0