- openstack-discuss - lists.openstack.org

[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

[all][elections][ptl] Opt in to CIVS voting system
by Ian Y. Choi 20 Feb '26

20 Feb '26

The election uses the Condorcet Internet Voting Service (CIVS). Due to CIVS policy, to vote in private CIVS polls, you must opt in to email communication. To opt in, please enter your Gerrit email address in the following page before the start of the election Feb 25, 2026 23:45 UTC, and confirm with the code that will be sent to you via email. https://civs1.civs.us/cgi-bin/opt_in.pl If you have any questions, please contact the election officials. https://governance.openstack.org/election/#election-officials

1 0

Nova Multi-Cell Live Migration Issues
by Tyler Wilson 20 Feb '26

20 Feb '26

Hello All, I'm trying to get a 2 cell setup going as a test environment and am running into some troubles. I seem to be able to start VM's just fine, however when I try live-migrations I am getting this error: 2026-02-19 20:11:01.448 1 ERROR nova.conductor.manager [None req-91d4c1c6-a69f-41d4-a3ca-c0890bde0af8 - - - - - -] Migration of instance 73123ed9-d112-4030-945c-96c75a016d55 to host compute1 unexpectedly failed.: oslo_messaging.rpc.client.RemoteError: Remote error: RemoteError Remote error: CantStartEngineError No sql_connection parameter is established I see this on the following service logs nova-conductor (superconductor role only) nova-api nova-compute What is odd is that I don't see any activity in the cell-conductor when this happens, even with debug enabled. Here are the configured connection strings I have in each conductor/api/compute services: https://pastebin.com/raw/uuamtzsk Are these the correct database connection strings for each service? I'm basing this off the multi-cell diagram in the docs. The fact that the cell-conductors aren't showing any activity when this happens is throwing me off. I feel like I'm missing something here but I can't put my finger on it. Any help would be appreciated, thanks!

2 2

[release] Release countdown for week R-5, Feb 23 - 27
by Elõd Illés 20 Feb '26

20 Feb '26

Development Focus ----------------- We are getting close to the end of the 2026.1 Gazpacho cycle! Next week on February 26th, 2026 is the Gazpacho-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the 2026.2 Hibiscus cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on February 26th, 2026. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2026.1 branching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… February 26th, 2026 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also a good time for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Gazpacho-3 milestone (feature freeze): February 26th, 2026 (R-5 week) 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

Feb 19 Digital Sovereignty WG Recording + Next Steps
by Kendall Nelson 19 Feb '26

19 Feb '26

Hello All! Thank you to all those that were able to find the time to attend and participate in this week's meeting! For those that were not able to attend, here is the recording of today's meeting so that you can catch up and stay engaged with these efforts: https://zoom.us/rec/share/a5cXdx6RsWRNuGt8uqyQEgrVDNnIbexDag8NaUEzhcuyiUmTh… *Now, as far as next steps go: * - Soon, Allison and I will send around some samples of stance text for the landing page and we will *NEED* your feedback and opinions to make sure we have everything covered. - If you have a use case that you think would be good to share, please start working on those case studies ASAP! While we don't need them to launch the landing page (which is scheduled for March 20th-ish) the more content we have ready to go early on, the better! - If you are interested in helping with either of the other initial deliverables ( the comparison sheet or the best practices doc), please add your name to those sections of the etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG>. Also, if you have additional resources that would be helpful in crafting either deliverable, add them to the etherpad. Feel free to also get started throwing content in either as well! They will be living documents in draft form for a while, so nothing has to be perfect. Focus on just getting content in and we will polish things up later. When Allison and I send drafts of stances for review, we will also send out the poll for selecting the next meeting time which is slated for the week of March 9th, likely the 10th, 11th or 12th. Whew, that was a lot of information, but we have a lot of work to get done as a group! I am so excited to see this effort through with you all; we are a strong community and we are stronger together, so thank you for sharing your expertise and time with the Digital Sovereignty Working Group. -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 0