- openstack-discuss - lists.openstack.org

[manila][election][ptl] Carlos da Silva Candidacy for 2026.2 PTL
by Carlos Silva 13 Feb '26

13 Feb '26

Hello, I would like to announce my candidacy for Manila PTL for the 2026.2 (Hibiscus) cycle. I have been serving as Manila PTL for the past couple of releases and am happily investing time and energy into working with this very talented and passionate group of contributors. Over these releases, we have been creating more and more opportunities for contribution, ranging from code to involving cloud users and operators in our discussions to collect feedback. This helps us deliver valuable enhancements and fixes. We still have lots to do, and that includes enhancing our contributor experience. Therefore, in the upcoming cycle, I would like to direct our focus to: Eventlet: python-manilaclient is successfully migrated. We are now completing the migration in the manila code base, so we will focus on finalizing it and testing the changes we are making while moving away from eventlet. Tech debt: Continue the efforts to reach parity between Manila APIs and Manila UI, and complete the rootwrap -> privsep migration. VirtioFS: Closing the scenario testing gap for VirtioFS. Mentorship: Continue shepherding and encouraging more active reviewer participation and preparing new core reviewers. Communication: Reshaping the way we communicate and document our team priorities. Thank you for your consideration. Carlos da Silva IRC: carloss

2 1

[release] Release countdown for week R-6
by Thierry Carrez 13 Feb '26

13 Feb '26

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non client library freeze" on February 19th, 2026. Only bugfixes 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/… In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (February 26th, 2026) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, February 26th, 2026. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/2026.1 branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/2026.1 branches are cut for a repo, the ability to approve any necessary backports into those branches for 2026.1 "Gazpacho" will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 19th, 2026 (R-6 week) Client library freeze: February 26th, 2026 (R-5 week) Gazpacho-3 milestone: February 26th, 2026 (R-5 week) Cycle Highlights Due: March 5th, 2026 (R-4 week) 2026.1 "Gazpacho" final release: April 1st, 2026 2026.2 "Hibiscus" (virtual) PTG: April 20-24, 2026 -- Thierry Carrez (ttx)

1 0

[neutron][ovn-bgp-agent] Fix for missing /etc/iproute2/rt_tables after iproute2 upgrade
by Maximilian Stinsky-Damke 13 Feb '26

13 Feb '26

Hi everyone, I wanted to bring attention to an issue that affects ovn-bgp-agent deployments after upgrading to newer versions of the iproute2 package. Problem: In newer iproute2 package versions, the default rt_tables file has been moved from /etc/iproute2/rt_tables to /usr. This change was introduced as part of iproute2's move to a "stateless" configuration pattern where configuration files are read from /etc first, falling back to /usr if they don't exist. You can see the related iproute2 commit here: https://github.com/iproute2/iproute2/commit/0a0a8f12fa1b03dd0ccbebf5f85209d… When iproute2 is upgraded on Rocky Linux (and other RHEL-based systems), if /etc/iproute2/rt_tables was modified, it gets moved to /etc/iproute2/rt_tables.rpmsave and the original file isn't recreated. See https://access.redhat.com/solutions/7123966 for more details. I suspect Debian-based systems have the same issue. The ovn-bgp-agent has a hard requirement on /etc/iproute2/rt_tables existing, which causes it to fail with a FileNotFoundError when it attempts to read the file: FileNotFoundError: [Errno 2] No such file or directory: '/etc/iproute2/rt_tables' The error occurs in ensure_routing_table_for_bridge() when the agent tries to check for existing routing table entries for bridges. Proposed Solution: I've proposed a fix that ensures the /etc/iproute2/rt_tables file exists before attempting to read it. The solution: 1. Creates a new privileged function ensure_routing_tables_file() that: - Creates the /etc/iproute2/ directory if it doesn't exist - Copies the default rt_tables file from /usr/share/iproute2/rt_tables to /etc/iproute2/rt_tables if the latter doesn't exist 2. Calls this function before reading rt_tables in ensure_routing_table_for_bridge() This approach maintains backward compatibility while handling the new iproute2 package structure gracefully. Bug Report: https://bugs.launchpad.net/ovn-bgp-agent/+bug/2141421 Proposed Patch: https://review.opendev.org/c/openstack/ovn-bgp-agent/+/976242 Has anyone else hit this issue? We didn't find any upstream fix for it yet, so we'd appreciate feedback on the patch. Thanks, Max

1 0

February 4 Meeting Recap & Next Steps
by Kendall Nelson 12 Feb '26

12 Feb '26

Hello folks! Thank you for all your participation thus far - watching the previous recording, answering the last poll, attending the meetings, etc. Here is the recording from today's meeting for those that were unable to attend it live: https://zoom.us/rec/share/9vo8njF87mFdFQhsYdZzYBrY3DSfeuo5t2EJIxMdV4CCtslQs… If you do watch, I would encourage you to add your name and details to the etherpad where we took notes on today's meeting: https://etherpad.opendev.org/p/Digital-Sovereignty-WG The next meeting date and time is to be determined by you all! Here is the poll to vote <https://beta.framadate.org/polls/fe703653fdd969cbdaf4/1e0eba4bc789b7067aa1/…> on a date/time between Feb 17th, 18th, and 19th. *I will set the deadline to vote for the end of the previous week - February 13. * Lastly, I want to remind folks of the homework we discussed on the call - using some of the words and phrases we brainstormed (and any others that get added) to craft a stance on why OpenInfra and our projects are able to support digital sovereignty. For more information on this discussion, please watch the recording of the recent meeting. Thanks! -Kendall

1 3

[neutron] Drivers meeting canceled Friday, February 13th
by Brian Haley 12 Feb '26

12 Feb '26

Hello Neutrinos: I am going to cancel tomorrow's Drivers meeting as there are no topics on the agenda. Just a reminder that our open spec list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[charms][sunbeam] Proposing Ahmad Hassan for sunbeam-core
by Guillaume Boutry 12 Feb '26

12 Feb '26

Hi all, Ahmad has been working for a year actively on Sunbeam charms and has proven to be an able reviewer and contributor. I'd like to propose Ahmad as a member of the sunbeam-core team. Cheers, Guillaume

3 2

[tc][election] gouthamr's TC Candidacy for 2026.2
by Goutham Pacha Ravi 11 Feb '26

11 Feb '26

Hello Stackers, I am submitting my candidacy for another term on the OpenStack Technical Committee. It's been two years since I was first elected, and I've served as TC Chair during this time. In these past two years, we've gotten some important things done: the CLA-to-DCO transition that our community asked for over a decade ago, extending the VMT's mandate to all project teams, setting clear expectations around project retirements and governance transitions, and consolidating our governance repositories. I'm proud of this work, and I'm running again because there's more to do. One thing that has become clear to me as Chair is that the people who keep OpenStack running by fixing gates, reviewing code across projects, reporting and triaging bugs, maintaining infrastructure and other myriad things don't get enough recognition for it. I'm hoping to change that by creating an objective, tangible way to acknowledge valuable contributions and enthuse our community to do more of this work. We are one of the largest open source projects in the world, and the community that's responsible for it is a bedrock needs constant care. I also want the TC to stay engaged with where cloud infrastructure is headed. OpenStack should be the free and open source choice for Sovereign Clouds and AI workloads. We'd do this not by chasing trends, but by ensuring our project teams are equipped and positioned for these use cases as they mature. On the governance side, I'll keep working to eliminate bottlenecks that slow our project teams down while maintaining the consistent maintenance model that has made our successful projects sustainable. The Technical Vision for OpenStack Clouds hasn't been modified in a while, and I'd like to help draft its next iteration. I'll take the opportunity to also include a process for evolving it. Lastly, two years on the TC have shown me how much we benefit from experienced, engaged leaders across our projects. I want to build mentoring pathways for future TC members, so our leadership pipeline is as durable as the software we produce. Thank you for your consideration. Goutham Pacha Ravi (gouthamr) Affiliation: Red Hat Inc. OpenInfra Profile: https://openinfra.dev/a/community/members/35705 Nomination: https://review.opendev.org/c/openstack/election/+/976553

1 0

[ci][nova][cinder][glance][devstack][swift] openstacksdk-functional-devstack job failing 100%
by melanie witt 11 Feb '26

11 Feb '26

Hey all, We noticed sometime today the openstacksdk-functional-devstack job appears to be failing 100% in multiple projects: https://zuul.opendev.org/t/openstack/builds?job_name=openstacksdk-functiona… The failing openstacksdk test is test_add_remove_router_interface [1]: ft1.1: openstack.tests.functional.cloud.test_router.TestRouter.test_add_remove_router_interfacetesttools.testresult.real._StringException: Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/openstacksdk/openstack/tests/functional/cloud/test_router.py", line 232, in test_add_remove_router_interface self.assertIn(key, iface) File "/home/zuul/src/opendev.org/openstack/openstacksdk/.tox/functional/lib/python3.12/site-packages/testtools/testcase.py", line 425, in assertIn self.assertThat(haystack, Contains(needle), message) File "/home/zuul/src/opendev.org/openstack/openstacksdk/.tox/functional/lib/python3.12/site-packages/testtools/testcase.py", line 509, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 'tenant_id' not in {'id': '57671080-6eb2-4c7f-9e64-c61edfa8995e', 'project_id': '1ef2e6c3fc2d4f6b92fdd8d49f0a05a1', 'port_id': '5b39bbfc-6d3d-440e-9c7a-e56e434ef897', 'network_id': '8aa6b6e2-e0c5-4f96-bb87-5509e30d340c', 'subnet_id': '6f52d8be-cf68-4552-b57d-37142cea65cc', 'subnet_ids': ['6f52d8be-cf68-4552-b57d-37142cea65cc']} which adds an interface to a router and expects the response parameter 'tenant_id' to be in the response. I looked for recently merged changes that could have possibly changed the router API response and it might be something similar to this change: https://review.opendev.org/c/openstack/neutron/+/972982 but I don't really understand if/how that could change the API. I'm not sure what the desired fix will be here, whether the API should be more backward compatible and/or if the openstacksdk test should be fixed by s/tenant_id/project_id/ or something else. Please hold your rechecks if CI has failed on your patch due to this. -melwitt [1] https://github.com/openstack/openstacksdk/blob/7afe210333ec236a14fc5fa2d4a5…

3 5

OpenStack Ops Radio Hour Survey - Timing, cadence and more
by Ildiko Vancsa 11 Feb '26

11 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 1

[ci][kolla] setuptools v82.0.0 breaks a bunch of things by removing pkg_resources
by Michael Still 11 Feb '26

11 Feb '26

Hey all, I've just noticed that setuptools v82.0.0 released todayish and breaks a bunch of Kolla builds (and probably other things) by removing pkg_resources. https://setuptools.pypa.io/en/stable/history.html#v82-0-0 has further details of the release. setuptools doesn't seem to be listed in upper-constraints, perhaps because it's often provided as a distro package? Michael

9 16