- openstack-discuss - lists.openstack.org

[Neutron] Bug Deputy Report Feb 9 - Feb 16
by Miro Tomaska 16 Feb '26

16 Feb '26

Hello Neutron, Here is the list of bugs from February 9th until the 16th. *High:* https://bugs.launchpad.net/neutron/+bug/2141546 - Neutron cleans OVN static routes it does not own Assigned: Martin Morgenstern *Medium:* https://bugs.launchpad.net/neutron/+bug/2141648 - [OVN] Allowed address pair with VMAC is not working in ML2/OVN Assigned: Rodolfo Alonso https://bugs.launchpad.net/neutron/+bug/2141908 - Optimize ``neutron.common.ovn.acl.update_acls_for_security_group`` Assigned: Rodolfo Alonso *Undecided: * https://bugs.launchpad.net/neutron/+bug/2141745 - Port in admin down does not send vif plugged events to nova Edit Unassigned *RFE:* https://bugs.launchpad.net/neutron/+bug/2141626 - [RFE] Remote-managed PF Plugging in OVN Driver Assigned: Dmitrii Shcherbakov *Waiting for more data:* https://bugs.launchpad.net/neutron/+bug/2141526 https://bugs.launchpad.net/neutron/+bug/2141530 It would be great to see full logs, but the OP is also using a Rocky release which is EOL. I will ask if this is also an issue on maintenance releases. https://bugs.launchpad.net/neutron/+bug/2141784 - Trunk: not able to filter trunks by their status It seems to work for me on master, waiting for more information -- Miro Tomaska

1 0

[kolla-ansible] Migration from OVS to OVN
by Winicius Allan 16 Feb '26

16 Feb '26

Hi kolla o/ I was searching to see if Kolla currently supports migration from OVS to OVN, and I've found this email thread [1]. I'd like to know if this feature has been implemented, and if so, what the necessary steps are. [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032785.h… Best regards

3 3

April 2026 PTG Team Signup Kickoff
by Kendall Nelson 16 Feb '26

16 Feb '26

Hello Everyone! The next OpenInfra PTG[1] will take place April 20-24, 2026 and registration for the event is now open[2]! For those new to the community, or perhaps just need the reminder, the PTG is a semi-annual event where project teams come together to hash out important details for the next six-ish months during a concentrated set of meetings that often include code sprints, bug fixing, design discussion, and cross project collaboration. To sign your team up, you must complete the survey[3] by March 1st at 7:00 UTC. If your team is not interested in participating, there is no need to fill out the survey. The contact information (email and preferably also IRC nickname) in the form will be used to share important details with moderators about team signup and further logistics. To ensure you receive all communications please double check and submit *ACCURATE* information! If you are not on IRC, please get on the OFTC network[4] and join #openinfra-events as much of the coordination for the event will be done in the #openinfra-events channel. You are also encouraged to familiarize yourself with the PTGBot documentation[5] as well. If you have any questions, please reach out to ptg(a)openinfra.org! Information about signing up for time slots will be sent to moderators shortly after the team signup deadline. -Kendall (diablo_rojo) [1] PTG Site: https://openinfra.org/ptg/ [2] PTG Registration: https://ptg.openinfra.org/ [3] Team Survey: https://openinfrafoundation.formstack.com/forms/apr2026_ptg_survey [4] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [5] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 1

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

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

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

15 Feb '26

Hello Stackers, We're 6 weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. We have a number of release deadlines scattered between this week and next, so it's an extremely busy time for project maintainers and our release management team. The nomination window for the combined TC and PTL elections is also closing this week (at 23:45 UTC on February 18, 2026) [2]. At last count, there were 27 project teams that still needed a PTL nominee. If you'd like to volunteer to be a PTL or if you think someone else should be, please ensure a nomination is submitted prior to the deadline. If you have questions regarding the process, please feel free to ask them on this mailing list or in the #openstack-election IRC channel on OFTC. The substantive governance activity in the past week was around the CI fixes concerning the regression in setuptools [3]. We've had to resurrect some "x-static" repositories in order for the OpenStack Dashboard project team to work around the changes from the upstream Python community. We're beginning to define the tested runtimes for the OpenStack 2026.2 "Hibiscus" release cycle [4]. Please take a look and give us your feedback. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held over IRC on February 10, 2026 [5]. We focused on our past action items, technical debt, and the ongoing election cycle. We have officially closed the chapter on Monasca by abandoning 173 open changes across several repositories, and conversely, we’re seeing a promising revival of Cyborg with a new PTL nominee and a fresh team structure. In the hope of staffing project teams that have a large cross-project impact, we've proposed PTL nomination directories for the Requirements and Oslo teams not just to solicit candidates, but to spark a discussion on how we better support these critical dependencies. We discussed navigating a "borked" gate due to the recent setuptools' pkg_resources deprecation [3]. While we are currently merging "band-aid" pins to restore CI stability on stable branches, the situation would have been significantly worse without the proactive work done by Stephen Finucane (stephenfin) and Takashi Kajinami (tkajinam) over the last few months. Their foresight has saved project teams from a much larger headache during the feature freeze rush that's underway. Finally, we called out to project teams to review the User Survey streamlining plan [6]. Our goal is to refine this feedback loop prior to the PTG in April [7] so we can make timely improvements. The next meeting of the OpenStack Technical Committee is on Tuesday, February 17, 2026. This meeting is being held at 0800 UTC, a time that's better suited for our contributors in the Eastern Hemisphere. Please feel free to add to the agenda on the meeting's wiki page, and thank you in advance for your participation [8]. === Governance Proposals === ==== Merged ==== - Add a script to abandon changes on retired repositories | https://review.opendev.org/c/openstack/governance/+/975594 - Onboard additional xstatic packages | https://review.opendev.org/c/openstack/governance/+/976513 ==== Open For Review ==== - 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 === 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+Cloud Native Con EU begins: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2026-04-20: OpenInfra PTG begins: https://openinfra.org/ptg/ === How to Contact the TC === You can reach the TC in several ways: 1. Email: send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. 3. Join us at our weekly meeting: The Technical Committee meets every Tuesday at 1700 UTC, except the third Tuesday of the month, when we meet at 0800 UTC [8]. 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] OpenStack "2026.2" Elections: https://governance.openstack.org/election/ [3] setuptools regression: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] Tested runtimes for 2026.2: https://review.opendev.org/c/openstack/governance/+/976691 [5] TC Meeting IRC Log, February 10 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-10-17.00.html [6] Streamlining the OpenStack User Survey: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] OpenInfra PTG: https://openinfra.org/ptg/ [8] TC Meeting Agenda, February 17 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[all][elections][ptl][tc] Combined PTL/TC 2026.2 cycle Election Nominations Last Days
by Ian Y. Choi 14 Feb '26

14 Feb '26

A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Feb 18, 2026 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at[1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. All members of the community are encouraged to confirm their email address and opt in to the CIVS election as described at: https://governance.openstack.org/election/#electorate Election statistics[2]: Nominations started @ 2026-02-04 23:45:00 UTC Nominations end @ 2026-02-18 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 5 days, 0:17:37 Nominations progress : 64.20% --------------------------------------------------- Projects[1] : 40 Projects with candidates : 13 ( 32.50%) Projects with election : 1 ( 2.50%) --------------------------------------------------- Need election : 1 (Horizon) Need appointment : 27 (Adjutant Barbican Cinder Cloudkitty Heat Keystone Masakari Mistral Neutron Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms Oslo Puppet_OpenStack Quality_Assurance Rally Requirements Skyline Storlets Sunbeam Swift Tacker Trove Venus Vitrage Zun) --------------------------------------------------- TC Candidates : 2 (5 Required) =================================================== Stats gathered @ 2026-02-13 23:27:23 UTC This means that with approximately 2 days left, 27 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.opendev.org/q/project:openstack/election+is:open+file:candid… have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[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

[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

[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

How to access OpenStack instances from the bastion node when deploying OpenStack using Kolla-Ansible
by ussefelboukhari＠gmail.com 11 Feb '26

11 Feb '26

In test environments, some users choose to build their infrastructure inside KVM virtual machines, while others use cloud instances such as EC2 bare-metal that support nested virtualization. After deploying OpenStack, many of them face a major issue: they are unable to access their OpenStack instances. I encountered the same problem myself. After several weeks of intensive troubleshooting, I eventually found a solution. That is why I would like to share this solution with others who face the same issue, and hopefully contribute to the OpenStack community by providing recommendations that could be added to the official OpenStack documentation.

2 1

[nova][elections][ptl] Application for the PTL role 2026.2
by René Ribaud 11 Feb '26

11 Feb '26

Hello, After serving as PTL for Flamingo and Gazpacho, I would like to announce my candidacy for the 2026.2 (Hibiscus) Nova and Placement PTL role. The previous cycle was somewhat unusual, as upstream contributions from several core contributors were impacted by internal changes within their organizations. Despite this, the community stayed engaged and resilient, and I am grateful for everyone who kept things moving forward. The Eventlet removal effort, which started earlier and significantly progressed during Flamingo and Gazpacho, should reach completion this cycle. This will be an important milestone and will allow us to introduce new changes more confidently. In 2026.2, I would like to focus on enabling forward-looking work such as confidential computing improvements, restarting collaboration with Manila around virtiofs, and further I/O performance improvements. The concrete priorities and scope of these efforts will be discussed and refined during the next PTG. In parallel, I will continue to improve review efficiency and maintain a welcoming and focused community. My goal remains simple: keep Nova and Placement robust, maintainable, and aligned with our users’ needs. I would be honored to continue serving in this role. Thanks, René

1 0

[kolla-ansible][rabbitmq] RabbitMQ cluster creation took too long
by Nguyễn Hữu Khôi 10 Feb '26

10 Feb '26

Hello. I am deploying OpenStack 2025.1 with Kolla-Ansible 2025.1 (master branch) using the latest images. However, when I created a RabbitMQ(4.0.x) cluster with 3 nodes, it took too long—around 12 minutes(it stucked at DB: virgin node -> run peer discovery). I then changed the images to RabbitMQ version 3.13.7, and it worked well. My OS: Ubuntu 24.01 Nguyen Huu Khoi

2 2

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 11 February
by Kees Meijs | Nefos 10 Feb '26

10 Feb '26

Hello Stackers, Tomorrow (that's 11 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 See you tomorrow! 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

How to change flavor or sg of a virtual machine with Ansible?
by Marco Favero 10 Feb '26

10 Feb '26

Hello, I'm new in this Openstack world and I love Ansible. I'm trying to use the openstack.cloud Ansible collection to manage virtual machines. There is no problems in adding or deleting a virtual machine (vm). The openstack.cloud.server module works very well. I'm in trouble if I want to update a vm. The server module has only the "present" state: the resource is not updated after the creation if I change something in the module parameters. So, I can't use openstack.cloud.server module in order to change the flavor or security group of an already existing vm. The "server_action" module is not useful because it has not update actions about sg or flavor. I tried the CRUD "resource" module in some way such as --- - name: Change resources hosts: localhost tasks: - name: Change flavor to vm openstack.cloud.resource: cloud: myStack service: compute type: server attributes: name: vm-name flavor_id: 22b4d2c2-0fff-437b-a67c-009244f89403 state: present wait: true but the play fails with fatal: [localhost]: FAILED! => {"changed": false, "extra_data": {"data": null, "details": "Invalid input for field/attribute server. Value: {'flavorRef': '22b4d2c2-0fd8-437b-a67c-009244f89403'}. Additional properties are not allowed ('flavorRef' was unexpected)" If I try with "flavor" or "security_groups" attributes in place of "flavor_id" the error doesn't change. Could you help me? My env is: [root@cnt-ansible]/workdir/openstack# ansible-galaxy collection list | grep openstack openstack.cloud 2.5.0 [root@cnt-ansible]/workdir/openstack# pip3 list | grep openstack openstacksdk 4.9.0 ansible [core 2.16.14] Thank you very much Kind Regards Marco

5 5

[neutron] Bug Deputy Report Feb 02 - Feb 09
by Terry Wilson 10 Feb '26

10 Feb '26

Hi Neutrinos, Below is the bug deputy report for last week: High ==== * https://bugs.launchpad.net/neutron/+bug/2141304 - [oslo master] neutron-periodic-workers crashing with ERROR neutron AttributeError: Can't pickle local object 'Mapper.__init__.<locals>.<lambda>' - Unassigned Medium ====== * https://bugs.launchpad.net/neutron/+bug/2139583 - neutron-openvswitch-agent native driver: Permanent flow loss after OVS restart due to unhandled 'unknown dpid' during rpc_loop - Unassigned - As Yatin mentioned last week, it looks valid. Reporter attached the requested logs and points to the code they think is responsible. * https://bugs.launchpad.net/neutron/+bug/2139581 - Updating router state fails due to NoneType error - Assigned to William Tripp - Patch uploaded by Rodolfo - https://review.opendev.org/c/openstack/neutron/+/975373 * https://review.opendev.org/c/openstack/neutron/+/975373 - TapMirrorPlugin should not allow execution of non implemented TaasPlugin methods - Assigned to Miro Tomaska * https://bugs.launchpad.net/neutron/+bug/2140291 - [network_segment_range] VM creation fails with a KeyError - Assigned to Kyuyeong Lee * https://bugs.launchpad.net/neutron/+bug/2141308 - ``LoggingServiceDriverManager`` should handle the update of ``rpc_required`` - Assigned to Rodolfo - Patch https://review.opendev.org/c/openstack/neutron/+/976130 Low === * https://bugs.launchpad.net/neutron/+bug/2140762 - Define a reasonable default value for the OVN FDB aging and removal limit - Assigned to Rodolfo, - Patch https://review.opendev.org/c/openstack/neutron/+/975908 * https://bugs.launchpad.net/neutron/+bug/2141320 - [neutron-fwaas] The FWaaS plugin is always loading the ``IptablesLoggingDriver`` - Unassigned

1 0

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

09 Feb '26

Hello Stackers, We're 7 weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. At the end of this week, Oslo libraries and python-openstackclient will observe a feature-freeze until we are past the coordinated release. Project teams are busy reviewing feature changes in "cycle-with-rc" deliverables [2] with the hope to observe feature freeze in two weeks (February 26, 2026). In the past week, the OpenStack Technical Committee reset the leadership model for the Oslo and Requirements project teams. This means that these project teams could nominate and elect a PTL during the ongoing elections [3]. We do this with cautious optimism to indicate to the wider community that project governance is hard and it's extremely valuable. Oslo and Requirements are two project teams that maintain deliverables that affect nearly every other OpenStack project. However, we've only at best received part-time interest in their maintenance. Project liaisons have told the TC that they would really like help in the form of newer maintainers. If you're thinking about joining these project teams and lending a hand, please let us know. In a similar vein, over the past several weeks, the TC has noted that the FIPS compliance goal has degraded in its purpose [4]. In the past few release cycles, more work has been put into maintaining test jobs and this has threatened to divert our limited resources. The effort to pull together testing across OpenStack projects has turned out to be too large for an individual to handle. Therefore, we've dropped the cross-community goal for the moment. For it to be revived, we would need a level of commitment from a team of individuals, a clear definition of what can be tested, how the tests will function, and who would maintain them. We understand that FIPS compliance can be essential for a subset of organizations or countries that OpenStack serves. The TC doesn't seek to push back on the goal, but we need specifics and resources that we can't dedicate at the moment. As a consequence, project teams can choose to tear down existing jobs, or choose to maintain them using their best judgment. Finally, the elections are underway. We are seeking nominations for 5 seats on the OpenStack Technical Committee and for PTLs across project teams, with the exception of the Freezer, Ironic, and Release Management teams that have decided to follow a Distributed Leadership Model for the 2026.2 release cycle. If you wish to nominate yourself, please note that the nominations need to be accepted by 23:45 UTC on February 18, 2026 [3]. I hope you are able to verify your eligibility to be a part of the electorate as well [5]. === Weekly Meeting === The OpenStack Technical Committee meeting on February 3, 2026 focused on our feedback loop on project health as we approach the Gazpacho Feature Freeze [6]. We discussed the OpenStack User Survey with Allison Price (aprice), VP of Marketing & Community at the OpenInfra Foundation. We've concluded that the survey’s current complexity has become a barrier for operators; our goal is to rebuild it from a clean slate. A thought was to move to an opt-in model for questions with which we can deliver a leaner, more impactful survey by August 2026. We hope that the survey will provide PTLs with actionable data rather than just historical noise. I encourage all project leads/liaisons to participate in the upcoming feedback sessions to ensure the insights you actually need for development are prioritized. [7] On the technical and governance front, we're supporting the revival of Cyborg by resolving Launchpad ownership issues and ensuring the team has the necessary core permissions to land release-critical patches before M-3. We also addressed the reality of declining synchronous meeting attendance in projects like Barbican; while we are comfortable with teams moving to ad-hoc or asynchronous coordination to match their contributor velocity, the TC remains firm that design discussions must stay public and logged. Finally, we discussed the ongoing elections and the difficult and thankless job of maintaining cross-functional project teams like Requirements, Oslo, and Release Management. A hat tip to you folks that volunteer to do this! The next meeting of the OpenStack Technical Committee is on Tuesday, February 10, 2026. It will be hosted on the #openstack-tc IRC channel on OFTC. Please find the agenda on the meeting's wiki page [8]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 - Reset the DPL model for Oslo project | https://review.opendev.org/c/openstack/governance/+/974929 - Reset the DPL model for requirements project | https://review.opendev.org/c/openstack/governance/+/974927 ==== Open For Review ==== - Add a script to abandon changes on retired repositories | https://review.opendev.org/c/openstack/governance/+/975594 - Revert "Revive os_monasca" | https://review.opendev.org/c/openstack/governance/+/974775 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] OpenStack "2026.2" Elections: https://governance.openstack.org/election/ [4] FIPS compliance goal dropped back to "proposed": https://governance.openstack.org/tc/goals/proposed/fips.html [5] Check your eligibility to vote: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-03-17.00.html [7] Streamlining the OpenStack User Survey: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] TC Meeting Agenda, February 10 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[cyborg] Restarting Weekly Cyborg IRC Meetings
by Ronelle Landy 09 Feb '26

09 Feb '26

Hello All, We would like to restart the weekly Cyborg IRC meetings on the #openstack-cyborg channel. Meetings were previously held on Fridays at 0600UTC - 0700UTC. Previous meetings notes can be found at [1]. Noting the graphical distribution of the initial engineers who wish to start contributing, there is a proposal to move the meetings to Tuesdays 14:00 -15:00 UTC. If there are no objections, the IRC meetings will start on Tuesday, February 17th at 14:00 UTC. Please join the discussions on channel and the meetings if you wish to contribute. Thank you, Ronelle [1] https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda

1 1

[Nova] Live migration failed / VM has latency with patch to add managed='no' flag to libvirt XML
by Chang Xue 09 Feb '26

09 Feb '26

Hi, We are upgrading from Jammy to Noble, and need to include the patch https://review.opendev.org/c/openstack/nova/+/967570?tab=comments so VMs could be created on Noble nodes. However, all of our existing VMs that were created without the patch could not be live migrated to Noble, and has latency in live migrating to Jammy WITH the patch. To be clear: Old VMs created on Jammy -> patch applied on Jammy and Noble -> VMs can be live migrated to Jammy now, but with latency (VMs are pingable almost 10 seconds after live migration completed); VMs can not be live migrated directly to Noble nodes. After live migrated to Jammy with latency, we could live migrate the VMs between Jammy nodes, and one-way to Noble nodes, without any latency. Would like to understand it more, is there any way to get rid of the latency issue? I tried to patch nova/virt/libvirt/migration.py to add managed='no' flag when migration is on fly, but it only allows me to live migrate the old VMs directly to Noble nodes, latency still exists. Thanks, Chang

4 11

[cinder][nova][os-brick] Guidance on cross-project driver contribution
by Alokedip Choudhuri 08 Feb '26

08 Feb '26

Hello Everyone, We are working on contributing a new Cinder driver for *Infoscale*. This implementation requires coordinated changes across three projects to support the full attachment lifecycle: 1. *Cinder:* The core driver implementation. 2. *os-brick:* The connector APIs have been implemented there 3. *Nova:* New driver implementation to support the required operations like, "attach, detach, extend" for the volumes provisioned through the InfoScale Backend. We have already registered blueprints for this work: - *Cinder Blueprint:* https://blueprints.launchpad.net/cinder/+spec/infoscale-cinder-driver - *Nova Blueprint:* https://blueprints.launchpad.net/nova/+spec/infoscale-nova-driver Since this is a cross-project effort, I would appreciate guidance on the preferred workflow for submitting patches across multiple repositories to ensure a smooth integration. Looking forward to your feedback and suggestions. Thanks & Regards Alokedip

3 2

[keystone] Questions about federation mapping rules for academic research
by Sait, Abubakur Abdulgader S 07 Feb '26

07 Feb '26

Hello Keystone community, I am a PhD student researching privacy in federated identity systems. My work focuses on OpenStack Keystone federation, specifically how mapping rules process attributes from external Identity Providers. I would appreciate any insights from operators or developers about real-world federation deployments. My questions are: About mapping rules: 1. How many mapping rules do you typically have per federated IdP? 2. How often do these rules change after initial deployment? 3. Do you commonly use regex conditions, or mostly exact match conditions like any_one_of and not_any_of? About attributes: 4. How many attributes do you typically receive from federated IdPs? 5. For multi-valued attributes, how many values does a typical user have? About privacy: 6. Do you have privacy requirements affecting federated attributes? Any response would help my research. I am happy to share findings with the community when completed. Thank you for your time. Best regards, Abubakur Sait PhD Student, Wright State University, Dayton, OH, USA

1 0