- openstack-discuss - lists.openstack.org

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

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

[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

[neutron][all] No module named 'packaging.pylock' failures
by Brian Haley 22 Feb '26

22 Feb '26

Hi, Started seeing this failure yesterday in the neutron-functional job: ModuleNotFoundError: No module named 'packaging.pylock' Full ouptput at https://paste.opendev.org/show/bawqTgzkecxaK5DVEEAA/ I figured it was another issue with a new release of the packaging library as I see a 26.0 now, but upper-constraints is pinned to ==25.0 so I don't see how it's being pulled-in. The logs do show 26.0 being used at the end so I'm confused. I even tried to do a quick pin but it's still using 26.0: https://review.opendev.org/c/openstack/neutron/+/977556 Have any other projects seen this? Is 26.0 causing this or is it another interaction between libraries? Thanks for any help, -Brian

2 3

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 20 Feb '26

20 Feb '26

Hi Tacker team, Due to a holiday in Japan and most of team members aren't join, I'm cancelling meeting this week. Regards, Yasufumi

1 0