January 2026 - openstack-discuss - lists.openstack.org

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

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

[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

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

[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

[kolla][cinder] strange behavior with 2 storage nodes
by Alexander Luedtke 05 Feb '26

05 Feb '26

Hello Everyone, I have an strange behavior here on an cinder installation deployed with Kolla: The Setup: - 1 Controller node - some compute nodes - 2 Storage nodes (storage0, storage2) - later it should be 3. both with NFS Setup what is working. both storage nodes are shown on Skyline. The Problem: 1. in Skyline both storage nodes are shown but both are shown with the same size of one of both. 2. When I created a Volume then it was created on the other host as shown (in DB, skyline and so on) Anyone an idea what I can do to correct this problems ? Thanks a lot for your help ! Alexander -- Alexander Luedtke Systemadministrator Technische Universität München TUM School of Computation, Information and Technology Chair of IT Security Garching Boltzmannstr. 3 Room 01.08.036 85748 Garching b. Muenchen Tel. +49 89 289 18039 www.sec.in.tum.de

1 1

[ironic] A first-class physical location API?
by Jay Faulkner 03 Feb '26

03 Feb '26

Something I've seen come up in a few discussions over the last couple of cycles is the need for Ironic to contain more useful information about the physical world. It's made me wonder if there's an opportunity to add bigger support for physical characteristics/locations? I'm thinking metadata like: - Datacenter the server is in - Computer room (or other DC subdivision) - Row - Rack - Slot # - Physical cabling (e.g. what switches you might be connected to and how) Do other folks see this need? I'm trying to tease out if there's something here or not, so just curious about use cases and what people think. -Jay

4 5

[neutron] IPv6 DVR for OVN - Seeking feedback on patch review prospects
by Maximilian Stinsky-Damke 03 Feb '26

03 Feb '26

Hello, I'm reaching out about the IPv6 DVR feature for OVN (bug #1998609: https://bugs.launchpad.net/neutron/+bug/1998609) and the associated patch (https://review.opendev.org/c/openstack/neutron/+/867513) As noted in the bug comments, Roberto Bartzen Acosta maintained this patch across multiple release cycles, but it hasn't received reviews from core maintainers and is currently blocked by merge conflicts. Roberto mentioned that the feature hasn't been getting traction despite the work put in. This feature would enable distributed routing for IPv6 GUA addresses in OVN deployments, similar to how IPv4 FIPs work with DVR today. The spec was approved and merged (https://review.opendev.org/c/openstack/neutron-specs/+/867979) indicating community interest. Before I invest time rebasing the patch and resolving merge conflicts, I'd like to understand: 1. Are there technical or architectural concerns that have prevented review? 2. Is there a reason this hasn't been prioritized, or is it a matter of reviewer availability? 3. Would core maintainers be willing to review if the patch is rebased and updated? I'm happy to do the rebase work, but I'd prefer not to spend time on something that won't be merged. Any guidance on the status and viability of this feature would be appreciated. Thanks, Max

2 5

OVN issues
by engineer2024 03 Feb '26

03 Feb '26

HI, I am trying to setup an extport host to act as host for an sriov vm IP. Set it up using ovs-vsctl set Open_vSwitch . external_ids:ovn-cms-options=enable-chassis-as-extport-host But when a vm is created with this sriov port, it is not able to reach the metadata service at 169.254.169.254. Inside the vm vm:~# ip r 10.1.0.0/24 dev ens5 proto kernel scope link src 10.1.0.20 169.254.169.254 via 10.1.0.12 dev ens5 proto dhcp src 10.36.160.60 metric 100 On the node marked as the extport host for this vm's ip, its ovn-controller log shows --------- 2026-01-29T11:52:26.922Z|00069|binding|INFO|Setting lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf up in Southbound 2026-01-29T11:52:27.849Z|00070|binding|INFO|Releasing lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf from this chassis (sb_readonly=0) 2026-01-29T11:52:27.851Z|00071|binding|INFO|Setting lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf down in Southbound 2026-01-29T11:52:28.480Z|00072|binding|INFO|Claiming lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf for this chassis. 2026-01-29T11:52:28.480Z|00073|binding|INFO|a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf: Claiming fa:16:3e:f3:82:f9 10.1.0.20 2026-01-29T11:52:28.482Z|00074|binding|INFO|Setting lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf up in Southbound 2026-01-29T11:52:29.486Z|00075|binding|INFO|Releasing lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf from this chassis (sb_readonly=0) 2026-01-29T11:52:29.489Z|00076|binding|INFO|Setting lport a7c94e2b-58f1-4a6d-8c73-1d0e6f92b4cf down in Southbound ------------ It is fluctuating intermittently and not stable. Why is this flapping ? Also the metadata proxy is running fine on the extport host ip netns exec ovnmeta-7d9a4c21-1e6f-4f2b-9a84-3c8e1b7d62f0 telnet 169.254.169.254 80 Trying 169.254.169.254... Connected to 169.254.169.254. # ip netns exec ovnmeta-7d9a4c21-1e6f-4f2b-9a84-3c8e1b7d62f0 ss -ln | grep 80 tcp LISTEN 0 1024 169.254.169.254:80 <http://169.254.169.254/> 0.0.0.0:* # ps -ef | grep ovn-meta root 408634 1 9 11:52 ? 00:02:45 neutron-ovn-metadata-agent (/openstack/venvs/neutron-29.2.3/bin/python3 /openstack/venvs/neutron-29.2.3/bin/neutron-ovn-metadata-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_ovn_metadata_agent.ini) root 408673 1 0 11:52 ? 00:00:00 haproxy -f /var/lib/neutron/ovn-metadata-proxy/7d9a4c21-1e6f-4f2b-9a84-3c8e1b7d62f0.conf root 421770 388277 0 12:21 pts/12 00:00:00 grep --color=auto ovn-meta

2 1

Digital Sovereignty WG Kickoff Summary + Recording + Next Steps
by Kendall Nelson 01 Feb '26

01 Feb '26

Hello Everyone! Thank you to those that were able to attend our first meeting of the Digital Sovereignty Working Group! We had excellent representation from many different countries and organizations. Lots of good perspective and ideas were shared and I am eager to get started! As promised, here is the recording for those that were not able to attend: https://zoom.us/rec/share/QLyhngha_pgXEc2736oPEdDGWz_UI8IZLbHbJGyDWLv7nt4es… And here is the etherpad where we took notes, but will also continue to use going forward for meeting agendas and general working group coordination: https://etherpad.opendev.org/p/Digital-Sovereignty-WG If you watch the recording, please feel free to add your name to the attendees list in the etherpad, just make an additional note that you watched the recording. Everyone is encouraged to add to the notes and content in the etherpad whether they attended the meeting live or watched the recording. The goal is to capture as much participation as possible. Digital sovereignty is a very important topic with an ever developing list of accompanying legislation and we need everyone's perspective! Now, while there wasn't much in the way of immediate todo's, the one request that I have is that folks fill out this poll so that we can select a meeting time <https://beta.framadate.org/polls/5f355daf8e4329e1cd52> for the next one (during the first week of February). Responses to this poll are allowed until January 28th. -Kendall

1 2

[keystone][openstack-helm][kolla] Is it safe to run the Keystone wsgi application in multiple threads?
by Vladimir Kozhukalov 30 Jan '26

30 Jan '26

Hi Keystone team, I am writing to ask someone from the Keystone team to give their opinion regarding whether it is safe to run the Keystone wsgi app in multiple threads in the same process. I see [1] Kolla team allows users to configure the number of processes but not the number of threads. We in Openstack-Helm have a similar review request [2] and we had a small discussion about this. I would really appreciate it if someone from the Keystone team can give their opinion on [2]. Thanks. [1] https://opendev.org/openstack/kolla-ansible/src/branch/master/ansible/roles… [2] https://review.opendev.org/c/openstack/openstack-helm/+/971751 -- Best regards, Kozhukalov Vladimir

2 1

[manila] 2026.1 Gazpacho mid cycle: Feb 3rd and 5th
by Carlos Silva 30 Jan '26

30 Jan '26

Hello, everyone! The Manila team's mid cycle is right around the corner. As in the mid cycles we have hosted in the past, we will focus on understanding where we are with our plans for 2026.1 Gazpacho, as well as host collaborative review sessions for the features being introduced, helping speed up the review process. All sessions will be recorded and shared in the OpenStack Manila YouTube channel [2]. We will meet from 15:00 to 16:30 UTC on the 3rd and 5th of February in this meetpad bridge [3]. We are using an etherpad to gather topics [1], so in case you would like to add something to discuss with the manila community, please update the etherpad. The .ics file contains all meeting details [4] and can be imported to your calendar tool of preference. [1] https://etherpad.opendev.org/p/manila-gazpacho-mid-cycle [2] https://www.youtube.com/@openstackmanila [3] https://meetpad.opendev.org/p/manila-gazpacho-mid-cycle [4] https://gist.github.com/silvacarloss/0ba9a53c7b9b3d98690f1b6495baa502 Looking forward to it! Regards, carloss

1 0

[cinder] 2026.1 Midcycle reminder
by Jon Bernard 30 Jan '26

30 Jan '26

Hello all, this is a reminder that our midcycle/review meeting will take place on Wednesday February 11th from 1400 to 1600 UTC. The etherpad we'll be using is here [1], please add any topics and review information that you would like to cover. [1]: https://etherpad.opendev.org/p/cinder-gazpacho-midcycles -- Jon

1 0

[tc][cyborg] Proposal for Cyborg Project Revitalization and Maintenance
by Sean Mooney 30 Jan '26

30 Jan '26

Hi everyone, I'm not really sure how to start this conversation, so I'm just going to jump right to the point. I am writing to the Cyborg community and the Technical Committee to discuss the current state of the project and share my intent to help ramp up maintenance efforts for this cycle and beyond. I recently discussed this briefly on the #openstack-tc channel, but I wanted to bring it to the public list for broader visibility. Now that the new year has started, I am reaching out to express my intent to spend time contributing to the health and maintainability of Cyborg over the next few cycles. If I'm being entirely honest, it does not feel like it has been 18 months since I started down the same path with Watcher, but I have been asked to try and restart Cyborg development in a similar way as we did with Watcher. Recently, I have been submitting patches and performing initial code reviews, but it is clear that review latency and accumulated technical debt have become significant bottlenecks. To help unblock the project and prepare for future development, I am volunteering to lead a focused cleanup effort. My primary goals for this cycle are: 1. Addressing neglected technical debt and stale patches: I have already identified several critical areas including oslo.db and oslo.service compatibility, microversion-parse naming, and the long-overdue eventlet removal. I have also identified a backlog of bot-proposed patches for release notes and .gitreview that need manual intervention. 2. Improving CI/CD stability and alignment: While we have made progress moving failing jobs from Jammy to Noble and adding Python 3.13 support, significant debt remains. For example, the cyborg-tempest-plugin lacks stable branch jobs post-2024.2 while still carrying EOL branch definitions. We also lack grenade/SLURP upgrade testing which is vital for project health. 3. Managing release-related work and project metadata: Cyborg needs active management for release note preludes, marketing highlights, and RC/GA tagging. Furthermore, our Launchpad project requires cleanup to ensure bugs and features are tracked against the correct series, and team ownership needs to be aligned with current OpenStack standards. Note: I have checked PyPI (https://pypi.org/project/openstack-cyborg/) and it is correctly owned by openstackci from what I can tell. We are close to the end of the 2026.1 cycle, so my immediate priority is fixing the critical gaps to ensure Cyborg's inclusion in the 2026.1 release, followed by a longer-term plan for maintenance in 2026.2 and new feature development. To execute this, I am requesting that the core team consider adding me to the cyborg-core group. I am also volunteering as Release and TACT-SIG liaison for the remainder of this cycle. For 2026.2, I propose adopting the Distributed Project Leadership (DPL) model to better distribute these responsibilities. One or two others who have been helping me revive Watcher over the last year will be joining me in this effort over the coming weeks. We hope to split the release, TACT, and security roles between us to ensure consistent coverage unless we get other volunteers :) Our overall goal is to restart the Nova-Cyborg integration work to improve the accelerator management UX (attach/detach, move operations, etc.). To reach that point, we must first pay down technical debt and rebuild an active core review team. I have prepared a high-level maintenance roadmap and task list here: https://etherpad.opendev.org/p/cyborg-maintance-2026.2 which I intend to use to track this work. I look forward to hearing your thoughts. The first step should probably to discuss this at the next tc meeting and to follow up with the existing core team for comment. If there are no objections, I will coordinate with the TC and Infra team regarding the necessary permission updates. Regards, Sean

3 4

[neutron] Drivers meeting canceled Friday, January 30th
by Brian Haley 29 Jan '26

29 Jan '26

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

1 0

RabbitMQ version for OpenStack Epoxy
by Francesco Di Nucci 28 Jan '26

28 Jan '26

Hi all, I'm upgrading from OpenStack Caracal to Epoxy on EL, using RDO packages. I see that CentOS Stream Messaging SIG still packages RabbitMQ 3.8, that is EOL. Should I still use it or switch to a more recent release, like 3.13 or pass to 4.x series? Has anyone tried it? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

5 8

[ironic] Tuesday morning (PST) recurring review jam!
by Jay Faulkner 28 Jan '26

28 Jan '26

Hey all, The GR-OSS OpenStack team is going to be hosting a weekly Ironic review jam for our internal contributors from 10a-11a (PST) on Tuesdays for the foreseeable future. We'll be reviewing anything and everything in Ironic or Ironic-adjacent repos (not just GR changes). If you want an invitation, I'm happy to add anyone, just ask! Thanks, Jay Faulkner

1 0

[election][all][tc] Looking for volunteers to shadow election officials
by Goutham Pacha Ravi 28 Jan '26

28 Jan '26

Hello Stackers, The OpenStack election process is critical to our community. While we have historically relied on a dedicated group of volunteers to serve as election officials, we want to broaden community knowledge of this process. We are looking to recruit new election officials to help manage this important task responsibly. If you are interested in shadowing the upcoming PTL and TC elections for 2026.2, please join #openstack-election on OFTC and let us know. We would appreciate assistance with reviewing candidacies and administering the different election phases [1]. Please note that election officials should ideally be neutral parties who are not contesting these elections themselves. Thanks, Goutham Pacha Ravi (gouthamr) [1] https://governance.openstack.org/election/

1 0

[CI][Zuul] Enhancing Zuul log readability with a custom highlighter script
by Piotr Milewski 28 Jan '26

28 Jan '26

Hi everyone, I would like to share a small tool I've developed to make our daily work with Zuul logs a bit easier and more efficient. As we all know, navigating through long lists of Zuul test results in Gerrit can sometimes be tedious when trying to quickly distinguish between critical failures and non-voting ones. To address this, I created a Tampermonkey script that automatically highlights job statuses with intuitive colors: - Green: SUCCESS - Red: FAILURE (Voting) - Orange: FAILURE (Non-voting) This visual distinction allows for a much faster assessment of the "health" of a patch set at a single glance. How to use it: 1. Install the Tampermonkey extension (available for Chrome, Firefox, Edge, and others) from: https://www.tampermonkey.net/ 2. Add the script available at my Gist: https://gist.github.com/vurmil/b89f3846424bc9231f56da3ce8f8ac16 Please find a screenshot below showing the script in action: [image: image.png] I hope you find this useful! Feel free to share your feedback or suggestions for further improvements. Best regards,

2 1

[blazar] My Blazar service is having issues with MariaDB.
by Eduardo Morais 28 Jan '26

28 Jan '26

The first time the problem appeared, it wouldn’t allow listing the leases. So I went to check the logs and this log showed up. I restarted the service, and less than a week later the same thing happened again.Does anyone have any idea why this error keeps happening, and what the possible consequences would be of increasing the maximum number of connections? LOG: ERROR oslo.service.loopingcall sqlalchemy.exc.TimeoutError: QueuePool limit of size 2 overflow 50 reached, connection timed out, timeout 30.00 (Background on this error at: https://sqlalche.me/e/14/3o7r) 2026-01-26 15:11:45.671 7 ERROR oslo.service.loopingcall 2026-01-26 15:11:45.672 7 WARNING oslo.service.loopingcall [None req-3c69a13f-1bf2-4ace-9b7e-81249a6db22b - - - - - -] Function 'blazar.manager.service.ManagerService._process_events' run outlasted interval by 20.00 sec 2026-01-26 15:11:45.673 7 DEBUG blazar.manager.service [None req-3c69a13f-1bf2-4ace-9b7e-81249a6db22b - - - - - -] Trying to get events from DB. _process_events /var/lib/kolla/venv/lib/python3.10/site-packages/blazar/manager/service.py:233 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall [None req-3c69a13f-1bf2-4ace-9b7e-81249a6db22b - - - - - -] Fixed interval looping call 'blazar.manager.service.ManagerService._process_events' failed: sqlalchemy.exc.TimeoutError: QueuePool limit of size 2 overflow 50 reached, connection timed out, timeout 30.00 (Background on this error at: https://sqlalche.me/e/14/3o7r) 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall Traceback (most recent call last): 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_service/loopingcall.py", line 67, in func 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall return f(*args, **kwargs) 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.10/site-packages/blazar/manager/service.py", line 234, in _process_events 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall events = db_api.event_get_all_sorted_by_filters( 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.10/site-packages/blazar/db/api.py", line 102, in decorator 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall res = func(*args, **kwargs) 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.10/site-packages/blazar/db/api.py", line 227, in event_get_all_sorted_by_filters 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall return IMPL.event_get_all_sorted_by_filters(sort_key, sort_dir, 2026-01-26 15:12:15.675 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.10/site-packages/blazar/db/sqlalchemy/api.py", line 355, in event_get_all_sorted_by_filters

2 3

[taskflow] Taskflow hangs with graph_flow with 50 tasks
by Alfredo Moralejo Alonso 28 Jan '26

28 Jan '26

Hi, In the watcher project, taskflow is used to execute actionplans which are composed of actions (taskflow tasks) with certain dependencies between them. We have found that taskflow has problems when actionplans start having problems when having parallelization >=2 around 35 actions and with 50 actions can take up to 45 minutes to find the next task after the first is done. Is anyone having this kind of scalability issues with taskflow? I've reported the issue in https://bugs.launchpad.net/taskflow/+bug/2139228 and provided a minimal reproducer with only taskflow. Any help or recommendation about a different way to implement it is appreciated. Alfredo

2 1

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

28 Jan '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: * Cinder: The core driver implementation. * Os-brick: The connector APIs will be implemented there * 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 Choudhuri

1 0

[openstack][octavia]Resize a Load Balancer
by Nguyễn Hữu Khôi 27 Jan '26

27 Jan '26

Hello. I see that patch https://review.opendev.org/c/openstack/octavia/+/890215 Could I ask why we cannot merge it? Nguyen Huu Khoi

3 6

[tc][freezer][watcher][requirements][release][oslo][ironic] Please update your DPL liaisons
by Goutham Pacha Ravi 27 Jan '26

27 Jan '26

Hello project maintainers, To ensure project liaisons remain active and interested in their roles within the distributed leadership (DPL) model [1], the Technical Committee (TC) has created several reviews [2]. Project teams have until February 4, 2026, to oppose these changes and retain the DPL model for the 2026.2 "Hibiscus" release. After this deadline, we will seek Project Team Lead (PTL) nominations for these teams as part of the 2026.2 PTL elections [2]. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) [1] https://governance.openstack.org/tc/reference/distributed-project-leadershi… [2] https://review.opendev.org/q/hashtag:%22dpl-reset%22+status:open [3] https://governance.openstack.org/election/

1 0

[tc] [all] [security] Attestation service for confidential VMs: any existing project?
by Jean-Philippe Jung 27 Jan '26

27 Jan '26

Hi, As the work progresses for the support of confidential VMs on OpenStack (support for AMD SEV-SNP, Intel TDX, Arm CCA), is there any current effort/project to look at the key missing piece for Confidential Computing: Attestation. Attestation provides cryptographic proof that your code is actually running inside a genuine Trusted Execution Environment (TEE), not just someone claiming it is. Without attestation, confidential computing is meaningless—you'd be trusting the cloud provider's word that your data is protected, which defeats the entire purpose. Attestation generates a signed report from the hardware itself, containing measurements of the code, the TEE's identity, and proof the CPU is legitimate. This lets you verify before sending sensitive data that: the hardware is real, the enclave code hasn't been tampered with, and the environment matches your expectations. It's trust anchored in silicon, not promises. The Attestation service would have connections to at least to compute and storage, as the attestation service would be the final approver to release a VM decryption key after verifying that the hardware stack is unmodified and suitable to run an encrypted VM. Thank you, JP Jung

5 8

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 28 January
by Kees Meijs | Nefos 27 Jan '26

27 Jan '26

Hello Stackers, Tomorrow (that's 28 January) 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

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

26 Jan '26

Hello Stackers, We're 9 weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. In the past week, election officials set the dates for the combined election for Project Team Leads and for five seats on the OpenStack Technical Committee [2]. The nomination period begins at 23:45 UTC on February 04, 2026, and runs until 23:45 UTC on February 18, 2026. This may overlap with holiday periods around the world, so please feel free to submit your nominations early [3], and if you'd like, you could have someone else shepherd the nomination through in your absence. Official election updates will follow in a separate thread. Besides this, in the past week, the OpenStack-Ansible project team revived the os_watcher and os_freezer Ansible roles. There are several other governance updates that are undergoing the community's review. === Weekly Meeting === The TC hosted a weekly IRC meeting on January 20, 2026 [4]. We spent a significant amount of time discussing the future of our recommended web server stack, specifically regarding the eventual replacement of uWSGI. While uWSGI remains functional, its "maintenance mode" status and lack of HTTP/2 support are becoming bottlenecks for deployments. We discussed alternatives like Gunicorn and the Rust-based Granian, though the TC's primary goal here isn't to mandate a specific tool, but to clarify the distinction between CI convenience (DevStack-based testing) and production recommendations. Our high-level objective is to ensure that OpenStack services remain backend-agnostic (WSGI/ASGI compatible) while providing deployers with clear, updated documentation that reflects modern performance standards rather than legacy defaults. We also discussed adding a new community goal focused on supporting MariaDB/MySQL character set changes required by newer LTS releases of MariaDB. Doing this would drive consistency across services in maintaining database compatibility and stability. The next meeting of the OpenStack Technical Committee is today, January 27, 2026, at 1700 UTC. It will be hosted on the #openstack-tc IRC channel on OFTC. Please find the agenda on the meeting's wiki page [5]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Revive os_freezer role for OSA | https://review.opendev.org/c/openstack/governance/+/973364 - Revive os_watcher role for OSA | https://review.opendev.org/c/openstack/governance/+/973385 - Replace obsolete PCRE packages | https://review.opendev.org/c/openstack/governance/+/974074 ==== Open For Review ==== - Remove rbd-iscsi-client from release management | https://review.opendev.org/c/openstack/governance/+/972316 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 - Update mission statement for kolla project | https://review.opendev.org/c/openstack/governance/+/974421 - Remove barbican-ui from release management | https://review.opendev.org/c/openstack/governance/+/972315 === Upcoming Events === - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-01-31: FOSDEM 2026: https://www.meetup.com/brussels-openinfra-meetup-group/events/312867974 - 2026-02-26: 2026.1 "Gazpacho" Feature Freeze / Milestone 3 === 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 [5]. 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] 2026.2 OpenStack Elections: https://governance.openstack.org/election/ [3] How to submit a candidacy: https://governance.openstack.org/election/#how-to-submit-a-candidacy [4] TC Meeting IRC Log, Jan 20 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-01-20-08.00.html [5] TC Meeting Agenda, Jan 27 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Joining the Openinfra/Openstack community
by Hamed Enayatzare 26 Jan '26

26 Jan '26

Hi everyone, I’ve been working with OpenStack for several years, mostly around deployment and operations. I recently decided to get more involved with the community and start participating here. Looking forward to learning, sharing experiences, and contributing where I can. ‌Best Regads Hamed Enayatzare

3 3

[Neutron] Bug deputy report Jan 19-26
by Jakub Libosvar 26 Jan '26

26 Jan '26

Hi all, I was the bug deputy for the last week. There are two undecided bugs, one proactive from the Nova team and one that might already be solved in master, would be good to discuss at the next team meeting. Here is the full report: Medium ------ * Ensure no RPC clients are instantiated if ``rpc_workers=0`` https://bugs.launchpad.net/neutron/+bug/2139063 * [OVN] ``LogicalRouterPortEvent`` should discard routers not handled by Neutron API https://bugs.launchpad.net/neutron/+bug/2139067 Rodolfo already proposed a patch: https://review.opendev.org/c/openstack/neutron/+/974709 Low --- * Remove neutron-ovn-db-sync-util and OVNDbMonitor functional tests using various connection types https://bugs.launchpad.net/neutron/+bug/2139064 Slawek already proposed a patch: https://review.opendev.org/c/openstack/neutron/+/974691 Undecided --------- * Broken connectivity to external gateways for baremetal nodes https://bugs.launchpad.net/neutron/+bug/2138941 This one is actually fixed in master and we can discuss if it can be closed. * Live migration or any host update operation may require resetting NVRAM https://bugs.launchpad.net/neutron/+bug/2139077 This is a proactive report and it’s still not clear if there is any need from Neutron.

1 0

[nova] Ephemeral storage potential features
by Karol Klimaszewski 26 Jan '26

26 Jan '26

Hello, In my company (CloudFerro) we have developed two features related to nova ephemeral storage (with libvirt virt driver) - "SPDK-based ephemeral storage backend" and "Multiple ephemeral storage backend handling" (both described below). Would these features be appropriate to be added to upstream? If yes, then should I start with creating a blueprint and proposing a spec for each of them so it is more clear what we want to introduce? Of course not both at once, since there is some code that makes one work with the other. For us it would probably be best if we upstreamed "SPDK-based ephemeral storage backend" first and then upstreamed "Multiple ephemeral storage backend handling" Description of SPDK-based ephemeral storage backend: We add a new possible value for [libvirt]/images_type in nova.conf: spdk_lvol. If this value is set then local disks of instances are handled as logical volumes (lvols). of locally run SPDK instance (on the same compute as VM). See https://spdk.io/doc/logical_volumes.html#lvol for docs on this subject. These are essentially a part of local NVMe disk managed by SPDK. We create and manage those lvols by making calls from nova-compute to SPDK instance with RPC (https://spdk.io/doc/jsonrpc.html) using provided python library (https://github.com/spdk/spdk/blob/master/python/README.md) We attach those lvols to instances by exposing them as vhost-blk devices (see https://spdk.io/doc/vhost.html) and specifying them as disks with source_type='vhostuser'. This method of exposing NVMe local storage allows for much better I/O performance than exposing them from local filesystem. We currently have working: creating, deleting, cold-migrating, shelving, snapshots, unshelving VMs with this storage backend. We don't have live migration working yet but have it in plans. This feature includes changes only to nova. Description of Multiple ephemeral storage backend handling: We add a new configuration option [libvirt]/supported_image_types to nova.conf of nova-compute and change the meaning of [libvirt]/images_type to mean default image type. If libvirt:image_type extra_spec is specified in flavor then VM is scheduled on compute with appropriate image type in its [libvirt]/supported_image_types. We use potentially multiple DISK_GB resource providers and construct appropriate request groups to handle this scheduling. This spec is also used to fill driver_info.libvirt.image_type field of BDMs with destination_type=local of this VM. (driver_info is new JSON serialized field of BDM) Then in compute if BDM specifies this field we use its value instead of [libvirt]/images_type to decide on imagebackend to use for it. This method of handling multiple backends only works after being enabled by administrators by setting libvirt:image_type on all their flavors and running nova-manage commands that update existing VMs. Without enabling everything works as it was before. This feature includes changes to nova and some new traits in os-traits (One per possible value of [libvirt]/images_type + one extra) Best regards, Karol Klimaszewski

2 7

[horizon] Cancelling weekly meeting on Jan 28
by Tatiana Ovchinnikova 23 Jan '26

23 Jan '26

Hello team, I will not be around for our meeting on January 28, so as we discussed earlier I am cancelling it. See you all on February 4. With kind regards, Tatiana

1 0

[Kolla] ovn failed to install because of notifying handlers
by Michal Arbet 23 Jan '26

23 Jan '26

Hi, Ovn is failing currently, https://aa9bea214d792ca72a31-ab9965a682a78200f296c9df29ce08ed.ssl.cf2.rackc… Caused by https://review.opendev.org/c/openstack/kolla-ansible/+/940428 I probably have a fix ..root cause is that item of course don't have a key ... Kevko Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on January 23, 2026
by Ildiko Vancsa 23 Jan '26

23 Jan '26

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the first OpenStack Ops Radio Hour[1] in 2026 is scheduled to happen on __January 23rd, 2026 at 1300UTC,__ which is next 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. Topics for this call: - Plans for 2026 - Ops Radio Hour Survey draft: https://etherpad.opendev.org/p/openstack_ops_radiohour_survey 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 January 23rd! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 2

[Neutron] VPNaaS one to many subnets
by Robert N 23 Jan '26

23 Jan '26

Dear Community, I'm trying to configure VPNaaS between 2 sites, both sites have one openstack subnet with 2 networks. left side. subnet 192.168.0.0/24 gw 192.168.0.1 subnet 172.0.0.0/16 - the scope for this is just local network, it doesn't have to be routed outside. this subnet is broke into /24 subnets and assigned to differnt nodes on the network, and they are reachable with explicit routes on the router. It's basically a kubernetes pod network, and the routes are managed by openstack-cloud-controller-manager. right side subnet 192.168.1.0/24 gw 192.168.1.1 subnet 172.1.0.0/16 I need connectivity between the 2 sites on both layers 192.... and 172... so I tried to endpoint groups, a local of type subnet and a peer of type cidr with the cidrs `192.168.0.0/24,172.0.0.0/16` and respectively ` 192.168.1.0/24,172.1.0.0/16`. With this setup the vpn connection doesn't come up. If I create the peer cidr with only one cidr `192.168.0.0/24` and respectively `192.168.1.0/24` the vpn connection becomes active and works as expected for the 192... netowrks. I tried adding manually the routes for the 172.0.0.0/16 on one side and 172.1.0.0/16 o the other side with to the same gateway `169.254.0.2` but it doesn't work. I'm wondering how could I configure the VPN to have both networks routed 192... and 172... Appreciating any input on the topic. Cheers, Robert

1 0

Mark your calendars! April 2026 PTG Dates & Registration
by Kendall Nelson 22 Jan '26

22 Jan '26

Hello Everyone! The dates are set for the next PTG[1]! It will take place April 20-24, 2026! Registration is now open[2] and free for all to attend. Please stay tuned! Soon I will be sending the team sign up survey to collect those teams interested in participating this April. -Kendall Nelson (diablo_rojo) [1] PTG Website: https://openinfra.org/ptg/ [2] PTG Registration: https://ptg.openinfra.org/

1 0

[kolla] Dropping support for building and deploying InfluxDB
by Michał Nasiadka 22 Jan '26

22 Jan '26

Hello Koalas, Kolla project plans to drop support for InfluxDB, given that current version supported by the project is v1, which is in End of Life state. We haven’t seen any interest in introducing v2 support and given that the core team also has no interest in doing that - we’re dropping support. See https://review.opendev.org/q/topic:%22kolla_drop_influxdb%22 Michal

1 0

Zuul failures for openstack-tox-py313
by Nimesh Desai 22 Jan '26

22 Jan '26

Hi, I am observing following error in the zuul run the given patch. There have been no changes in this patch recently, but zuul started failing for this package error. Is this also seen in other patches? Patch: [IBM SVf Driver] Define meaningful names for error constants | https://review.opendev.org/c/openstack/cinder/+/959683 Zuul target: openstack-tox-py313 Zuul error: https://zuul.opendev.org/t/openstack/build/9491515d2dbb473c922ba1e3ba13b19b No package matching 'libpcre3-dev' is available 2026-01-19 03:30:29.510623 | TASK [bindep : Install distro packages from bindep] 2026-01-19 03:30:31.956565 | debian-trixie | ERROR 2026-01-19 03:30:31.956930 | debian-trixie | { 2026-01-19 03:30:31.957003 | debian-trixie | "msg": "No package matching 'libpcre3-dev' is available" 2026-01-19 03:30:31.957062 | debian-trixie | } Regards, Nimesh Desai

4 4

[neutron] Next week CI meeting cancelled
by Yatin Karel 21 Jan '26

21 Jan '26

Hello Neutron Team !! As discussed in the last CI meeting I will not be around upcoming Monday, so cancelling the meeting. We will now have our next CI meeting on 02nd February. -- Thanks and Regards Yatin Karel

1 0

[dev][nova] Intel TDX support
by Anton Iacobaeus 21 Jan '26

21 Jan '26

Hi, I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova. I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release. From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed. Early feedback or any concerns and guidance are very welcome! [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support Best Regards, Anton

3 3

[all][oslo][cinder][glance][nova][sdk][trove] Upcoming migration of whereto to PCRE2
by Takashi Kajinami 21 Jan '26

21 Jan '26

Hi ! I'm sending this email so that you'd be aware of an upcoming breaking change in the whereto library, because you might need to update your projects (especially their bindep.txt files) to adopt your projects to the change. The whereto library is a tiny library to generate redirect rules in Apache and has been used in documentation build in several projects. This library has been dependent on python-pcre, which requires the following packages. - libpcre3-dev in Debian-based operating systems (such as Debian or Ubuntu) - pcre-devel in RHEL-based operating systems (such as RHEL or CentOS Stream) However these packages are no longer provided by newer operating systems and we have to replace these by PCRE 2. - Debian removed libpcre3-dev because PCRE 3 is obsolete and it is recommended to replace it by PCRE 2 [1]. - RHEL 10 removed PCRE and PCRE 2 is a recommended replacement. I've already proposed the change[1] of whereto to replace python-pcre by pcre2 (which requires pcre2 packages from OS). I'll create a new release of whereto shortly after this change is merged. Once the new release hits the upper constraints, libpcre3-dev and pcre-devel in bindep.txt in each repository should be replaced. See [3] to learn how the change should look like. So far I'm planning to take care of this transition, but it'd be nice if I can ask for some attention about it. Please let me know if you have any question. Thank you, Takashi [1] https://lists.debian.org/debian-devel/2021/11/msg00176.html [2] https://review.opendev.org/c/openstack/whereto/+/970061 [3] https://review.opendev.org/c/openstack/whereto/+/970061/4/bindep.txt -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 1

[tc][ops] Any consensus for what's next after uWSGI ?
by opensource＠rfc2549.ca 20 Jan '26

20 Jan '26

Hi, This thread from 2023 generated some discussion around uWSGI being in maintenance mode but my search doesn't yield more recent developments around $topic. uWSGI is still in maintenance mode 3 years later. Back at the Epoxy PTG, openstack-ansible had a topic [1] to figure a replacement but after checking with Dimitri, this has not happened yet and they are still relying on uWSGI at this time. I was curious if the community had opinions on what the next "standard" wsgi runtime might be from options like gunicorn, uvicorn or granian, to name a few. I realize this is not so much a problem for individual OpenStack projects but like mentioned in [0], it is much nicer if any of the options are well supported/documented from an operator perspective. Thanks ! [0]: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/03234… [1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

4 4

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

19 Jan '26

Hello Stackers, We're 10 weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Now that we're past milestone-2 of this release cycle, project teams are actively reviewing implementation patches for specifications. The next project-wide deadline is the feature freeze (February 26, 2026), but please consult the release calendar to see project-specific deadlines in the interim. In the past week, the OpenStack Technical Committee reprised a weekly meeting after a month and caught up on several ongoing governance concerns. The governance of the "keystoneauth" repository was moved from the Keystone project team to the OpenStackSDK project team where we think it will see better reviewer attention. Apart from that, there are several open governance proposals that are being reviewed by the community. === Weekly Meeting === The OpenStack TC met over IRC on January 13th 2026 on the #openstack-tc channel on OFTC to kick off the year by synchronizing on several high-level initiatives [2]. This includes the transition to the 2026.2 "Hibiscus" release cycle and aligning our technical efforts with the Foundation's upcoming marketing themes [3] and the "Next Level" board goals [4]. We also discussed the immediate sunsetting of Bitergia dashboards [5]. As we transition to LFX, the committee spoke about the importance of project metrics such as review participation and merge timelines. Programmatically graphing this sort of information needs context-awareness and the dashboards must not rely on inaccurate assumptions about contributors' email addresses, working hours or time zones. We reiterated a critical resource gap within the Ansible SIG. The openstack.cloud collection remains a dependency for official projects like OpenStack-Ansible and Kolla, yet it currently lacks sufficient review bandwidth; we are looking for volunteers to help sustain this deliverable. Finally, we discussed the effort to support AlmaLinux on non-v3 x86 processors to maximize hardware reuse; while we have immediate workarounds for DevStack, we are seeking a native OVN package build on this platform. The next meeting of the OpenStack TC is today, January 20th 2026 at 0800 UTC. Please note this earlier time; it accommodates our APAC colleagues. The meeting will be hosted on the #openstack-tc channel on OFTC and the agenda is available on the meeting's wiki page [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Move keystoneauth under OpenStackSDK governance | https://review.opendev.org/c/openstack/governance/+/971178 ==== Open For Review ==== - Revive os_freezer role for OSA | https://review.opendev.org/c/openstack/governance/+/973364 - Revive os_watcher role for OSA | https://review.opendev.org/c/openstack/governance/+/973385 - Remove rbd-iscsi-client from release management | https://review.opendev.org/c/openstack/governance/+/972316 - Remove barbican-ui from release management | https://review.opendev.org/c/openstack/governance/+/972315 - Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 === Upcoming Events === - 2026-01-27: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-01-31: FOSDEM 2026: https://www.meetup.com/brussels-openinfra-meetup-group/events/312867974 - 2026-02-26: 2026.1 "Gazpacho" Feature Freeze / Milestone 3 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] TC Meeting IRC Log, Jan 13 2026:https://meetings.opendev.org/meetings/tc/2026/tc.2026-01-13-17.01.html [3] 2026 OpenStack Marketing and Messaging Priorities: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] Taking OpenStack to the Next Level in 2026: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenStack Dashboards: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Jan 20 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] Bug deputy Jan 12 - Jan 18
by Helen Chen 19 Jan '26

19 Jan '26

Hello Neutrinos: This is the list of bugs created during the last week: * High: ** Neutron-ovn-db-sync-util cleans ACL rules not really related to security groups at all (https://bugs.launchpad.net/neutron/+bug/2138430) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973648 ** [OVN] Exception when a ``Logical_Router_Port`` is deleted (https://bugs.launchpad.net/neutron/+bug/2138468) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973584 * Medium: ** [OVN] Exception during the port UP setup if the LSP has been deleted (https://bugs.launchpad.net/neutron/+bug/2138477) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973599 ** [OVN] LRP not present in ``check_redirect_type_router_gateway_ports`` (https://bugs.launchpad.net/neutron/+bug/2138484) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/973602 Thanks, Helen

1 0

[openstack][share]Openstack Workload Balancer
by Nguyễn Hữu Khôi 17 Jan '26

17 Jan '26

Hello, I have a script to make Openstack workload balance(CPU and RAM). I would like to share it. This script is not perfect but I hope it will be useful for you. https://github.com/nguyenhuukhoi/OpenstackWBalancer Nguyen Huu Khoi

1 0

[CVE-2026-22797] OpenStack keystonemiddleware: Privilege Escalation via Identity Headers in External OAuth2 Tokens (CVE-2026-22797)
by Jeremy Stanley 16 Jan '26

16 Jan '26

==================================================================== OSSA-2026-001: Privilege Escalation via Identity Headers in External OAuth2 Tokens ==================================================================== :Date: January 15, 2026 :CVE: CVE-2026-22797 Affects ~~~~~~~ - Keystonemiddleware: >=10.0.0 <10.7.2, >=10.8.0 <10.9.1, >=10.10.0 <10.12.1 Description ~~~~~~~~~~~ Grzegorz Grasza with Red Hat reported a vulnerability in the external_oauth2_token middleware for keystonemiddleware. This middleware fails to sanitize incoming authentication headers before processing OAuth 2.0 tokens. By sending forged identity headers such as X-Is-Admin-Project, X-Roles, or X-User-Id, an authenticated attacker may escalate privileges or impersonate other users. All deployments using the external_oauth2_token middleware are affected. Patches ~~~~~~~ - https://review.opendev.org/973499 (2024.1/caracal) - https://review.opendev.org/973497 (2024.2/dalmatian) - https://review.opendev.org/973496 (2025.1/epoxy) - https://review.opendev.org/973495 (2025.2/flamingo) - https://review.opendev.org/973494 (2026.1/gazpacho) Credits ~~~~~~~ - Grzegorz Grasza from Red Hat (CVE-2026-22797) References ~~~~~~~~~~ - https://launchpad.net/bugs/2129018 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-22797 Notes ~~~~~ - The unmaintained/2024.1 branches will receive no new point releases, but patches for them are provided as a courtesy. - This bug was possible because the middleware only conditionally set certain headers (e.g., X-Is-Admin-Project was only set when the token had admin privileges), leaving spoofed values intact when conditions were not met. - The fix adds a call to remove_auth_headers() at the start of request processing to sanitize all incoming identity headers, matching the behavior of the main auth_token middleware. - The external_oauth2_token middleware was introduced in keystonemiddleware 10.0.0. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

2 2

Proposed 2026.2 "Hibiscus" release schedule
by Thierry Carrez 16 Jan '26

16 Jan '26

Hi everyone, Here is the proposed schedule for the 2026.2 "Hibiscus" release: https://review.opendev.org/c/openstack/releases/+/973377 For easier review, you can access the HTML rendering at: https://92fe49c75c4839534367-ca89416a8fe69de9445ee46610790deb.ssl.cf5.rackc… It's a 26-week-long cycle that places final release on Sep 30, 2026. Please comment on the review if you have objections to this or would like to make a case for targeting another week for the 2026.2 release. Thanks! -- Thierry Carrez (ttx)

1 0

[nova] does resize work with swap & no-swap flavor combo for image-backed server having vol attached
by tomergaurav1031＠gmail.com 16 Jan '26

16 Jan '26

Hi Team, I’ve encountered resize causing issues if source flavor has swap-disabled and target flavor have it enabled or vice-versa. It results into duplicate vdb error. Following are the steps:- 1 Create an image-backed(no volume attached) instance with flavor having swap disabled. 2 Create a volume and attach it with the instance (e.g. get attached at /dev/vdb). 3 Resize it to a bigger flavor which has swap & ephemeral enabled. 4 It results into error complaining about duplicate vdb:- libvirt.libvirtError: XML error: target 'vdb' duplicated for disk sources '/var/lib/nova/instances/1860acb4-012f-4528-b2ef-XXXXX/disk.swap' Should one not do resize with swap & no-swap flavor combo? Please provide thoughts/suggestions for the same. Thanks, Gaurav

3 4

[nova] [kolla-ansible ]help with nova image-cache cleaning interval
by garcetto 16 Jan '26

16 Jan '26

good morning, using kolla-ansible and trying to lower nova image-cache cleaning interval. I setup this value, but seems doing nothing despite the vms are deleted by far more than 600 secs, any help? where is a log of it? nano /etc/kolla/config/nova.conf " [image_cache] image_cache_manager_interval=600 remove_unused_base_images=true remove_unused_original_minimum_age_seconds=600 remove_unused_resized_minimum_age_seconds=600 " kolla-ansible -i multinode reconfigure --tags=nova thank you.

1 0

[neutron][ovn-bgp-agent] ovs bridges down causes error when configuring route table
by anas.jouhdy＠gmail.com 15 Jan '26

15 Jan '26

Hi, I am trying to use the OVN BGP agent (nb_ovn_bgp_driver with the exposing method underlay) and I would like to share a difficulty that I found, it might be related to the specific deployment that I have using Kayobe. I find that by default my openvswitch bridges appear to be down when I list them with "ip link". From what I saw in some forums this is a normal behaviour. The thing is that the OVN BGP agent uses ip link, for example here [1], to add route to a table link to these bridges and if there are down, this raise an error(pyroute2.netlink.exceptions.NetlinkError: (100, 'Network is down')). When I set the bridge state UP with "ip link" it solves the issue but this solution is not reboot persistent. Is it really a normal behaviour to have the openvswitch bridges down or is it a problem that I need to investigate on my configuration ? If this is a normal behaviour, anyone found a workaround that could be resilient in production (that is reboot persistent) ? Do not hesitate if you need more information on my configuration ! [1]: https://opendev.org/openstack/ovn-bgp-agent/src/branch/master/ovn_bgp_agent…

3 2

[cinder] festival of reviews friday 2026-01-16
by Brian Rosmaita 14 Jan '26

14 Jan '26

Hello Argonauts, This is a reminder that the twice-monthly Cinder Festival of Reviews will be held at the end of this week on Friday 16 January. who: Everyone! what: The Cinder Festival of Reviews when: Friday 16 January 2026 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

Upcoming metrics dashboard changes
by Ildiko Vancsa 14 Jan '26

14 Jan '26

Hi OpenStack community, Since the OpenInfra Foundation joined the Linux Foundation, we have been looking into opportunities to take advantage of the frameworks and tool sets that the Linux Foundation has, and some of you and your organizations are already familiar with. While the dashboards are still being built I would like to let you know that, as part of that effort, we will switch to LFX Insights[1] as the metrics dashboard for OpenInfra projects, including OpenStack, starting on __January 15, 2026.__ A couple things to note: - The new OpenStack metrics dashboard[2] is already available, but it is __still under active construction.__ - The set of metrics that is displayed on the new dashboard will not be identical with the metrics on the dashboard provided by Bitergia. - LFX Insights does not display affiliation information for individuals who are listed on the dashboard as contributors, for privacy reasons. However, if you already have an LF account[3], you will be able to check and update your affiliation information. Or, you can create a new LF account[4]. - You can learn more about the dashboard in the LFX Insights documentation[5]. - If your organization is an OpenInfra Foundation / Linux Foundation member already, the LF Organization Dashboard[6] is also available for a more company-centric view. The OpenStack Bitergia metrics dashboard[7] remains available __until January 14, 2026.__ Please let me know if you have any questions. Best Regards, Ildikö [1] https://insights.linuxfoundation.org/ [2] https://insights.linuxfoundation.org/project/OpenStack/ [3] https://openprofile.dev/ [4] https://docs.linuxfoundation.org/lfx/sso/create-an-account [5] https://insights.linuxfoundation.org/docs/introduction/what-is-insights/ [6] https://lfx.linuxfoundation.org/tools/organization-dashboard/ [7] https://openstack.biterg.io/ ——— Ildikó Váncsa Director of Community OpenInfra Foundation

4 7

[dev][ops][tc] Taking OpenStack to the Next Level in 2026
by Jeremy Stanley 13 Jan '26

13 Jan '26

At the informal OpenInfra Governing Board get-together in France immediately before the Summit, directors talked about how they might "drive projects to the next level." In a follow-up thread on the public board mailing listi[*], Julia posited: > If we perform a risk assessment ourselves, what social and > technical aspects would come to mind? How can we move those items > forward? This was delegated to the foundation staff, whose executive management chose it as one of our three goals[**] for 2026: "Elevate OpenInfra projects to their next level" To this end, community managers and other staff have collaborated to draft areas of focus for ourselves with associated success measurements relevant to each OpenInfra Project. In the case of OpenStack, this is what we came up with: "Lowering the barriers to participate in OpenStack through clear and visible avenues and forums to get involved and collaborate, increased reviewer bandwidth and efficiency, and simplified user survey." The idea is that the foundation staff, through a multi-pronged approach, can coordinate a number of initiatives we've got underway for the year such as closer collaboration between operator-oriented groups and SIGs, continuation of the Bridging the Gap effort, planned improvements to www.openstack.org content, and giving the User Survey a much needed tune-up. Efficacy will be determined in various ways including impact on code review response times, sharing/adoption of more efficient communication behaviors across teams, cross-pollination in operator activities, increased feedback from surveys, and more effective reliance on relevant sections of the website. I'm bringing this draft plan to the mailing list to solicit community feedback, in preparation for an upcoming presentation to the board of directors. Keep in mind that the point of this exercise is to better use my time and the time of my colleagues on the staff of the OpenInfra Foundation in service of OpenStack, not to make more work for leaders and project maintainers nor to set technical direction as that's not our place. I just want to make sure that this plan is sensible and doesn't conflict with community expectations, while putting our limited resources into the right activities. If anyone has concerns or improvements to suggest please feel free to follow up in this thread or voice them to me directly (ideally over the coming week), or to your representatives on the OpenInfra Governing Board (who will be the ones to ultimately approve what we come up with). As always, thanks for everything you do in the name of OpenStack! [*] https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.… [**] https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th… -- Jeremy Stanley

1 0

[openstack-ansible] : Galera DB backup on Epoxy release
by keshav bareja 13 Jan '26

13 Jan '26

Hi Team We have recently upgraded to the Openstack-ansible Epoxy [2025.1] release. In this release Galera mariadb is upgraded to MariaDB 11.4.8. We have a daily DB backup crontab setup for the backup and before the Epoxy release we were using the below command to take the backup and now it doesn't work anymore. mysqldump --opt --all-databases > "openstack_$(date +'%Y-%m-%d_%H-%M-%S').sql" Can you please recommend the way to take the Galera DB backup now? I can see the command mariadb-dump, can we use the options below? mariadb-dump \ --all-databases \ --single-transaction \ --quick \ --skip-lock-tables \ --skip-add-locks \ --routines \ --events \ --triggers \ > "openstack_$(date +'%Y-%m-%d_%H-%M-%S').sql" Regards Keshav

2 3

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 14 January
by Kees Meijs | Nefos 13 Jan '26

13 Jan '26

Hello Stackers, Tomorrow (that's 14 January) 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

[tc][all] OpenStack Technical Committee Weekly Meeting Agenda (2026.1/R-11)
by Goutham Pacha Ravi 12 Jan '26

12 Jan '26

Hello Stackers, Happy New Year! After a 4-week break, the weekly TC meeting returns on January 13th 2026, Tuesday. It will be held in the #openstack-tc channel on OFTC between 1700 UTC and 1800 UTC. Please find the agenda in the meeting's wiki page [1]. I hope you'll be able to join us! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

A focus on digital sovereignty in 2026
by Kendall Nelson 12 Jan '26

12 Jan '26

Hello! A growing trend around the globe that is especially relevant for OpenInfra is digital sovereignty. Now, while OpenStack has been engineered with fine grained control over the data being processed and saved in OpenStack VMs since its inception, it is not necessarily immediately obvious to the global tech industry just how secure and intentional OpenStack can be. As a community, we hope to grow awareness by collaborating on a targeted effort to promote understanding of the ways in which OpenStack and other OpenInfra technologies enable digital sovereignty. To kick off this effort we plan to host a meeting on January 20th at 7:00 UTC. This first meeting will focus on setting the stage and defining goals for the year (examples could include crafting concrete deliverables, a gathering of case studies, enumeration of new features that could grow the digital sovereignty use case, etc). If you are interested in joining this meeting, please reply to this email and I can get you added to the calendar block. Please join us! -Kendall

1 0

[ptls][tc] 2026 OpenStack Marketing & Messaging Priorities
by Allison Price 12 Jan '26

12 Jan '26

Hi everyone, I wanted to share the big focuses for OpenInfra Foundation marketing around OpenStack messaging as I think this could be helpful as we think about overall milestones for OpenStack as well as positioning for Gazpacho and Hibiscus. I would love your help in identifying upstream and community work throughout the year that can help amplify these messaging priorities. OpenStack as the OSS Infrastructure Standard to Support AI Workloads This is a massive, quickly growing space, and it’s critical to keep OpenStack relevant as these systems get built out. It will be our primary focus for 2026. Specifically here, I want to learn more about efforts around hardware diversification efforts as this is a common concern I have heard when scaling to support AI workloads as more new hardware is introduced. Digital Sovereignty: Building a Global Network of Localized Clouds In Europe we have seen digital sovereignty provide a unique opportunity for OpenStack and we are seeing this extend to new geographies rapidly. This isn’t limited to code, but also to the OpenStack community culture in areas like open governance. Kendall Nelson will be following up on a larger effort around this soon. VMware Migration While VMware Migration will not be the primary focus this year, it continues to provide significant momentum for OpenStack adoption. As new features are built or strengthened to support this transition, we need to be prepared to share that more broadly. This is not an exhaustive list of messaging around OpenStack, but are priorities that the OpenInfra Foundation has identified to maximize OpenStack exposure in the broader open source and cloud market. If it would be helpful, I am happy to join an OpenStack TC meeting or schedule an ad hoc meeting to discuss these priorities and any feedback or concerns you may have as well as opportunities to maximize impact. Thanks, Allison Allison Price VP of Marketing & Community, OpenInfra Linux Foundation p: +1-214-686-6821 e: allison(a)openinfra.dev e: aprice(a)linuxfoundation.org

1 0

[cinder] volume migration and multipathing
by Karl-Heinz Preuß 12 Jan '26

12 Jan '26

Hi Everyone, I'm trying to migrate cinder volumes from one backend to another. Namely I'm migrating from an HPE Nimble Storage backend to a Ceph backend. My Problem: the volume migration speed is kinda sluggish - around 100 MB/s. I can read from a Nimble backed volume way faster. And of course the Ceph can also write more than 1GB/s. After quite some debugging, the problem seems to be: cinder uses multipathing to access the Nimble backed volumes. But for some reason cinder's volume migration explicitly doesn't use multipathing. (I found "multipath=false" in the cinder logs when looking for my slow migrations.) Question: is there a way to configure cinder to use multipathing for volume migrations when available. -- Karl-Heinz Preuß Linux Consultant Tel.: +49 1515 5806243 E-Mail: preuss(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537

2 1

[aco][ansible] PRs for the ansible collection
by James Hewitt-Thomas 12 Jan '26

12 Jan '26

Hi all, I've made a few proposed changes for the ansible collection, not sure on the process so thought I'd reach out and check. I've got them passing the zuul checks - is there anything I need to do to request reviewers, or is it just an it'll happen over time thing? There's no urgency, just making sure I'm not leaving things in limbo. Thanks, James.

1 0

[ceilometer] ceilometer metrics for list fields in event payloads
by NITIN GUPTA 12 Jan '26

12 Jan '26

Hello Ceilometer Team! Good Day! Could you please suggest, how to create ceilometer metrics for list fields in event payloads when creating Gnocchi resources? Looks like Ceilometer doesn't iterate over list fields in event payloads when creating Gnocchi resources. Is this a known issue? From the below Sample payload, I'm looking to create a separate metric for "vcpus" field (for example) from each item in "reservations", which is a list of dictionary type of data in the payload. 'payload': { 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'user_id': '2cf63f4ecf7740f5ac9ef4adfa4cdf5e', 'project_id': '07f1a09ab11543bb9080d260a98d812c', 'trust_id': '0037eb9121f04cdc94c39628a8354dde', 'start_date': '2025-12-15T16:18:00.000000', 'end_date': '2025-12-15T16:22:00.000000', 'status': 'PENDING', '*reservations*': [ { 'id': '1fffeb17-599d-441a-80e0-ca6d9044fd36', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'resource_id': 'c9daade3-4a85-4122-bec2-f34b7a849a01', 'resource_type': 'virtual:instance', 'status': 'pending', 'missing_resources': False, 'resources_changed': False, 'created_at': '2025-12-15 16:18:07', 'updated_at': '2025-12-15 16:18:10', '*vcpus*': 1, 'memory_mb': 1024, 'disk_gb': 20, 'amount': 1, 'affinity': None, 'resource_properties': '', 'flavor_id': '1fffeb17-599d-441a-80e0-ca6d9044fd36', 'aggregate_id': 292, 'server_group_id': None }, { 'id': '97df8162-d756-44c0-a27f-c832101577e8', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'resource_id': '4a3e20b1-5f63-46b1-a61b-13a267fd829a', 'resource_type': 'virtual:instance', 'status': 'pending', 'missing_resources': False, 'resources_changed': False, 'created_at': '2025-12-15 16:18:05', 'updated_at': '2025-12-15 16:18:07', '*vcpus*': 1, 'memory_mb': 1024, 'disk_gb': 20, 'amount': 1, 'affinity': None, 'resource_properties': '', 'flavor_id': '97df8162-d756-44c0-a27f-c832101577e8', 'aggregate_id': 291, 'server_group_id': None } ], 'events': [{'id': '4cea5a4f-53f4-4a69-969b-74a5869c7ab1', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'event_type': 'end_lease', 'time': '2025-12-15T16:22:00.000000', 'status': 'UNDONE', 'created_at': '2025-12-15 16:18:10', 'updated_at': None}, {'id': '63b51fc9-5eca-4729-8f5e-a3659e7db24b', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'event_type': 'start_lease', 'time': '2025-12-15T16:18:00.000000', 'status': 'UNDONE', 'created_at': '2025-12-15 16:18:10', 'updated_at': None}, {'id': 'bba382f6-47d8-4bb0-b3aa-0a65c6959ed9', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'event_type': 'before_end_lease', 'time': '2025-12-15T16:18:00.000000', 'status': 'UNDONE', 'created_at': '2025-12-15 16:18:10', 'updated_at': None}], 'name': 'lease-short-ins', 'created_at': '2025-12-15 16:18:05', 'updated_at': '2025-12-15 16:18:10', 'degraded': False } Best regards. -- NITIN GUPTA

3 12

[neutron] Bug deputy Jan 5 - Jan 11
by Rodolfo Alonso Hernandez 12 Jan '26

12 Jan '26

Hello Neutrinos: This is the list of bugs created during the last week: * Critical ** networking-bgpvpn and neutron-vpnaas unit tests arefailing due to tenant_id to project_id migration ( https://bugs.launchpad.net/neutron/+bug/2137489) Fixes merged and bug closed. * High: ** devstack deployment failing on stable/2025.1 branch without wsgi ( https://bugs.launchpad.net/neutron/+bug/2137540) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/972669 (tested in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/972266) * Medium ** neutron.tests.functional.services.bgp.test_ovn.TestBgpOvnLocking.test_locking_mechanism randomly fails with AssertionError: Second API did not lose the lock ( https://bugs.launchpad.net/neutron/+bug/2137467) In progress: https://review.opendev.org/c/openstack/neutron/+/972547 ** ``get_api_worker_id`` should not fail if ``uwsgi`` module is not installed (https://bugs.launchpad.net/neutron/+bug/2137715) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/972687 (needed up to 2025.2) Regards.

1 0

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 11 Jan '26

11 Jan '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

[release] Release countdown for week R-11, Jan 12 - 16
by Elõd Illés 09 Jan '26

09 Jan '26

Development Focus ----------------- We are now past the Gazpacho-2 milestone, and entering the last development phase of the cycle. Please review the late milestone-2 release patches at https://review.opendev.org/q/topic:gazpacho-milestone-2 if you have not done so already! Teams should otherwise be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (February 19th, 2026). Their stable branches are cut early. * Client libraries (think python-*client libraries) 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) 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. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (March 12th, 2026) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (March 26th, 2026) 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) Előd Illés irc: elodilles @ #openstack-release

1 0

[Nova] Proposal: NetApp FlexGroup Backend for Ceph-like Ephemeral Storage Performance on NFS
by Borra, Jayaanand 08 Jan '26

08 Jan '26

Hi everyone, Happy New Year to all! I hope you all had a great holiday season. I'm reaching out to share a proposal we've been working on that addresses a performance challenge many enterprises face with ephemeral storage in Nova. Context: Currently, OpenStack deployments running on NFS-based storage (like NetApp FlexGroups) face a significant performance penalty compared to Ceph RBD due to the QCOW2-over-NFS approach. The hypervisor manages Copy-on-Write operations, which introduces: * Double filesystem metadata overhead (QCOW2 on top of NFS) * CPU tax on compute nodes for CoW management * Slower instance provisioning compared to Ceph's instant cloning We are planning to implement solution that leverages NetApp's FlexClone technology through the ONTAP REST API to achieve Ceph-like performance while maintaining the operational simplicity of NFS. Essentially, we're offloading the cloning operation to the storage array itself, making instance creation a metadata-only operation (sub-second) with zero data copying. The implementation involves creating a new NetAppNfs image backend class in nova/virt/libvirt/imagebackend.py that calls the ONTAP REST API's /storage/file/clone endpoint instead of traditional file copy operations. I'm wondering if anyone has insights into: * Similar efforts: Has anyone explored or implemented storage-side cloning for other NFS vendors? * Design concerns: Any architectural red flags with this approach in the Nova driver? * Security practices: Best approach for managing storage credentials and oslo.privsep<vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html> integration? * Community interest: Would this be valuable for other NFS deployments? This will enable high-performance ephemeral storage from, so I'm curious if others have encountered this limitation and whether there's are any known limitation with this approach. Thanks in advance for any guidance or suggestions! Best regards, Jayaanand.

1 0

SECURITY BUG
by Umbrella Corporation 08 Jan '26

08 Jan '26

i found a vulnerability in your git repo so if i reported bugs and vulnerabilities can i get a reward bounty ?

3 3

OpenStack 2026.2 'H' Release Name Poll
by Allison Price 08 Jan '26

08 Jan '26

Hi everyone, Happy New Year! To kick off 2026, I wanted to share the poll to vote for the OpenStack 2026.2 release name, starting with the letter H. The poll will close this Thursday, January 8 at 1700 UTC. https://civs1.civs.us/cgi-bin/vote.pl?id=E_e4708c67d8d7e171&akey=e3b1514078… If you have any questions / comments, please let me know. Cheers, Allison

1 1

[designate] Question about NS record update restriction in multi-region PRIMARY/SECONDARY setup
by Sylvain 08 Jan '26

08 Jan '26

Hi everyone, I hope this email finds you well. I'm reaching out to the community because I'm encountering a limitation with Designate that I don't fully understand, and I'm hoping someone can shed some light on the reasoning behind it or suggest alternative approaches. My Setup I'm running a multi-region Designate deployment with: - 3 independent Designate instances (one per region) - Each instance has its own pool with a single nameserver: - Region 1: ns.region1.net. - Region 2: ns.region2.net. - Region 3: ns.region3.net. This default configuration works perfectly for most of our use cases where zones are region-specific. What I'm Trying to Achieve For certain domains, I need to set up a PRIMARY/SECONDARY configuration across all three regions: - Region 1: PRIMARY zone for example.com - Region 2: SECONDARY zone for example.com - Region 3: SECONDARY zone for example.com For this to work correctly, the PRIMARY zone needs to have NS records pointing to all three nameservers so that: 1. DNS clients can query any of the three nameservers 2. Zone transfers are properly configured between primary and secondaries The Problem When I try to update the NS recordset on the primary zone, I get the error: Updating a root zone NS record is not allowed Steps I'm following: # List recordsets to get the NS recordset ID openstack recordset list example.com. # Attempt to update the NS recordset openstack recordset set example.com. <ns-recordset-id> \ --record ns.region1.net. \ --record ns.region2.net. \ --record ns.region3.net. This happens even when authenticated as an admin user. Why the Default Workaround Doesn't Work I understand that one typical solution is to modify the pool configuration to include all three nameservers. However, this doesn't work in my case because: - I don't want to change the default pool settings since most zones should only use their local regional nameserver - Modifying the pool in Region 1 would affect *all zones* created there, not just the ones I want to replicate My Questions I'm trying to understand the design decisions here, and I'd really appreciate any insights: 1. What's the reasoning behind blocking NS record updates on root zones? I'm not seeing the security or technical concern that this protects against. 2. Is this restriction something that could potentially be made configurable via policy? For example, allowing zone owners to update their own NS records when they have legitimate multi-region or high-availability requirements. 3. Are there any alternative approaches I should be considering for this multi-region PRIMARY/SECONDARY setup that I might be missing? 4. Would the community be open to discussing a potential enhancement that makes this more flexible? I understand if there are concerns, but I'd love to understand them better. Use Case Context This is a fairly standard DNS architecture for high availability and geographic distribution. Many organizations need to run primary and secondary nameservers across different regions or datacenters, and being able to configure the NS records accordingly seems like it should be a supported use case. Thank you very much for taking the time to read this, and I appreciate any guidance or feedback the community can provide! Best regards, Sylvain.

2 2

vmware_nsxv
by Parsa Aminian 07 Jan '26

07 Jan '26

hello on kolla ansible neutron_plugin_agent: "vmware_nsxv" is showing this error : fatal: [control01]: FAILED! => {"changed": true, "msg": "Container exited with non-zero return code 1", "rc": 1, "stderr": "+ sudo -E kolla_set_configs\n2026-01-06 12:53:23.464 INFO Loading config file at /var/lib/kolla/config_files/config.json\n2026-01-06 12:53:23.465 INFO Validating config file\n2026-01-06 12:53:23.465 INFO Kolla config strategy set to: COPY_ALWAYS\n2026-01-06 12:53:23.476 INFO Copying service configuration files\n2026-01-06 12:53:23.476 INFO Copying /var/lib/kolla/config_files/neutron.conf to /etc/neutron/neutron.conf\n2026-01-06 12:53:23.489 INFO Setting permission for /etc/neutron/neutron.conf\n2026-01-06 12:53:23.501 INFO Copying /var/lib/kolla/config_files/nsx.ini to /etc/neutron/plugins/vmware/nsx.ini\n2026-01-06 12:53:23.501 INFO Setting permission for /etc/neutron/plugins/vmware/nsx.ini\n2026-01-06 12:53:23.502 INFO Copying /var/lib/kolla/config_files/ml2_conf.ini to /etc/neutron/plugins/ml2/ml2_conf.ini\n2026-01-06 12:53:23.512 INFO Setting permission for /etc/neutron/plugins/ml2/ml2_conf.ini\n2026-01-06 12:53:23.523 INFO Copying /var/lib/kolla/config_files/id_rsa to /var/lib/neutron/.ssh/id_rsa\n2026-01-06 12:53:23.524 INFO Setting permission for /var/lib/neutron/.ssh/id_rsa\n2026-01-06 12:53:23.524 INFO Writing out command to execute\n++ cat /run_command\n+ CMD='neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/vmware/nsx.ini '\n+ ARGS=\n+ sudo kolla_copy_cacerts\n+ sudo kolla_install_projects\n+ [[ ! -n '' ]]\n+ . kolla_extend_start\n++ [[ ! -d /var/log/kolla/neutron ]]\n++ mkdir -p /var/log/kolla/neutron\n+++ stat -c %a /var/log/kolla/neutron\n++ [[ 2755 != \\7\\5\\5 ]]\n++ chmod 755 /var/log/kolla/neutron\n++ [[ ! ubuntu =~ centos|rocky ]]\n++ /usr/bin/update-alternatives --display iptables\n++ KOLLA_LEGACY_IPTABLES=false\n++ [[ false == \\t\\r\\u\\e ]]\n++ sudo /usr/bin/update-alternatives --auto iptables\n++ sudo /usr/bin/update-alternatives --auto ip6tables\n++ . /usr/local/bin/kolla_neutron_extend_start\n+++ [[ -n 0 ]]\n+++ neutron-db-manage --subproject neutron upgrade head\nINFO [alembic.runtime.migration] Context impl MySQLImpl.\nINFO [alembic.runtime.migration] Will assume non-transactional DDL.\nINFO [alembic.runtime.migration] Context impl MySQLImpl.\nINFO [alembic.runtime.migration] Will assume non-transactional DDL.\nINFO [alembic.runtime.migration] Running upgrade -> kilo\nINFO [alembic.runtime.migration] Running upgrade kilo -> 354db87e3225\nINFO [alembic.runtime.migration] Running upgrade 354db87e3225 -> 599c6a226151\nINFO [alembic.runtime.migration] Running upgrade 599c6a226151 -> 52c5312f6baf\nINFO [alembic.runtime.migration] Running upgrade 52c5312f6baf -> 313373c0ffee\nINFO [alembic.runtime.migration] Running upgrade 313373c0ffee -> 8675309a5c4f\nINFO [alembic.runtime.migration] Running upgrade 8675309a5c4f -> 45f955889773\nINFO [alembic.runtime.migration] Running upgrade 45f955889773 -> 26c371498592\nINFO [alembic.runtime.migration] Running upgrade 26c371498592 -> 1c844d1677f7\nINFO [alembic.runtime.migration] Running upgrade 1c844d1677f7 -> 1b4c6e320f79\nINFO [alembic.runtime.migration] Running upgrade 1b4c6e320f79 -> 48153cb5f051\nINFO [alembic.runtime.migration] Running upgrade 48153cb5f051 -> 9859ac9c136\nINFO [alembic.runtime.migration] Running upgrade 9859ac9c136 -> 34af2b5c5a59\nINFO [alembic.runtime.migration] Running upgrade 34af2b5c5a59 -> 59cb5b6cf4d\nINFO [alembic.runtime.migration] Running upgrade 59cb5b6cf4d -> 13cfb89f881a\nINFO [alembic.runtime.migration] Running upgrade 13cfb89f881a -> 32e5974ada25\nINFO [alembic.runtime.migration] Running upgrade 32e5974ada25 -> ec7fcfbf72ee\nINFO [alembic.runtime.migration] Running upgrade ec7fcfbf72ee -> dce3ec7a25c9\nINFO [alembic.runtime.migration] Running upgrade dce3ec7a25c9 -> c3a73f615e4\nINFO [alembic.runtime.migration] Running upgrade c3a73f615e4 -> 659bf3d90664\nINFO [alembic.runtime.migration] Running upgrade 659bf3d90664 -> 1df244e556f5\nINFO [alembic.runtime.migration] Running upgrade 1df244e556f5 -> 19f26505c74f\nINFO [alembic.runtime.migration] Running upgrade 19f26505c74f -> 15be73214821\nINFO [alembic.runtime.migration] Running upgrade 15be73214821 -> b4caf27aae4\nINFO [alembic.runtime.migration] Running upgrade b4caf27aae4 -> 15e43b934f81\nINFO [alembic.runtime.migration] Running upgrade 15e43b934f81 -> 31ed664953e6\nINFO [alembic.runtime.migration] Running upgrade 31ed664953e6 -> 2f9e956e7532\nINFO [alembic.runtime.migration] Running upgrade 2f9e956e7532 -> 3894bccad37f\nINFO [alembic.runtime.migration] Running upgrade 3894bccad37f -> 0e66c5227a8a\nINFO [alembic.runtime.migration] Running upgrade 0e66c5227a8a -> 45f8dd33480b\nINFO [alembic.runtime.migration] Running upgrade 45f8dd33480b -> 5abc0278ca73\nINFO [alembic.runtime.migration] Running upgrade 5abc0278ca73 -> d3435b514502\nINFO [alembic.runtime.migration] Running upgrade d3435b514502 -> 30107ab6a3ee\nINFO [alembic.runtime.migration] Running upgrade 30107ab6a3ee -> c415aab1c048\nINFO [alembic.runtime.migration] Running upgrade c415aab1c048 -> a963b38d82f4\nINFO [alembic.runtime.migration] Running upgrade kilo -> 30018084ec99\nINFO [alembic.runtime.migration] Running upgrade 30018084ec99 -> 4ffceebfada\nINFO [alembic.runtime.migration] Running upgrade 4ffceebfada -> 5498d17be016\nINFO [alembic.runtime.migration] Running upgrade 5498d17be016 -> 2a16083502f3\nINFO [alembic.runtime.migration] Running upgrade 2a16083502f3 -> 2e5352a0ad4d\nINFO [alembic.runtime.migration] Running upgrade 2e5352a0ad4d -> 11926bcfe72d\nINFO [alembic.runtime.migration] Running upgrade 11926bcfe72d -> 4af11ca47297\nINFO [alembic.runtime.migration] Running upgrade 4af11ca47297 -> 1b294093239c\nINFO [alembic.runtime.migration] Running upgrade 1b294093239c -> 8a6d8bdae39\nINFO [alembic.runtime.migration] Running upgrade 8a6d8bdae39 -> 2b4c2465d44b\nINFO [alembic.runtime.migration] Running upgrade 2b4c2465d44b -> e3278ee65050\nINFO [alembic.runtime.migration] Running upgrade e3278ee65050 -> c6c112992c9\nINFO [alembic.runtime.migration] Running upgrade c6c112992c9 -> 5ffceebfada\nINFO [alembic.runtime.migration] Running upgrade 5ffceebfada -> 4ffceebfcdc\nINFO [alembic.runtime.migration] Running upgrade 4ffceebfcdc -> 7bbb25278f53\nINFO [alembic.runtime.migration] Running upgrade 7bbb25278f53 -> 89ab9a816d70\nINFO [alembic.runtime.migration] Running upgrade 89ab9a816d70 -> c879c5e1ee90\nINFO [alembic.runtime.migration] Running upgrade c879c5e1ee90 -> 8fd3918ef6f4\nINFO [alembic.runtime.migration] Running upgrade 8fd3918ef6f4 -> 4bcd4df1f426\nINFO [alembic.runtime.migration] Running upgrade 4bcd4df1f426 -> b67e765a3524\nINFO [alembic.runtime.migration] Running upgrade a963b38d82f4 -> 3d0e74aa7d37\nINFO [alembic.runtime.migration] Running upgrade 3d0e74aa7d37 -> 030a959ceafa\nINFO [alembic.runtime.migration] Running upgrade 030a959ceafa -> a5648cfeeadf\nINFO [alembic.runtime.migration] Running upgrade a5648cfeeadf -> 0f5bef0f87d4\nINFO [alembic.runtime.migration] Running upgrade 0f5bef0f87d4 -> 67daae611b6e\nINFO [alembic.runtime.migration] Running upgrade b67e765a3524 -> a84ccf28f06a\nINFO [alembic.runtime.migration] Running upgrade a84ccf28f06a -> 7d9d8eeec6ad\nINFO [alembic.runtime.migration] Running upgrade 67daae611b6e -> 6b461a21bcfc\nINFO [alembic.runtime.migration] Running upgrade 6b461a21bcfc -> 5cd92597d11d\nINFO [alembic.runtime.migration] Running upgrade 5cd92597d11d -> 929c968efe70\nINFO [alembic.runtime.migration] Running upgrade 929c968efe70 -> a9c43481023c\nINFO [alembic.runtime.migration] Running upgrade a9c43481023c -> 804a3c76314c\nINFO [alembic.runtime.migration] Running upgrade 804a3c76314c -> 2b42d90729da\nINFO [alembic.runtime.migration] Running upgrade 2b42d90729da -> 62c781cb6192\nINFO [alembic.runtime.migration] Running upgrade 62c781cb6192 -> c8c222d42aa9\nINFO [alembic.runtime.migration] Running upgrade c8c222d42aa9 -> 349b6fd605a6\nINFO [alembic.runtime.migration] Running upgrade 349b6fd605a6 -> 7d32f979895f\nINFO [alembic.runtime.migration] Running upgrade 7d32f979895f -> 594422d373ee\nINFO [alembic.runtime.migration] Running upgrade 594422d373ee -> 61663558142c\nINFO [alembic.runtime.migration] Running upgrade 61663558142c -> 867d39095bf4, port forwarding\nINFO [alembic.runtime.migration] Running upgrade 867d39095bf4 -> d72db3e25539, modify uniq port forwarding\nINFO [alembic.runtime.migration] Running upgrade d72db3e25539 -> cada2437bf41\nINFO [alembic.runtime.migration] Running upgrade cada2437bf41 -> 195176fb410d, router gateway IP QoS\nINFO [alembic.runtime.migration] Running upgrade 195176fb410d -> fb0167bd9639\nINFO [alembic.runtime.migration] Running upgrade fb0167bd9639 -> 0ff9e3881597\nINFO [alembic.runtime.migration] Running upgrade 0ff9e3881597 -> 9bfad3f1e780\nINFO [alembic.runtime.migration] Running upgrade 9bfad3f1e780 -> 63fd95af7dcd\nINFO [alembic.runtime.migration] Running upgrade 63fd95af7dcd -> c613d0b82681\nINFO [alembic.runtime.migration] Running upgrade c613d0b82681 -> c3e9d13c4367\nINFO [alembic.runtime.migration] Running upgrade c3e9d13c4367 -> 86274d77933e\nINFO [alembic.runtime.migration] Running upgrade 86274d77933e -> f4b9654dd40c\nINFO [alembic.runtime.migration] Running upgrade f4b9654dd40c -> a010322604bc\nINFO [alembic.runtime.migration] Running upgrade a010322604bc -> 263d454a9655\nINFO [alembic.runtime.migration] Running upgrade 263d454a9655 -> Ibac91d24da2\nINFO [alembic.runtime.migration] Running upgrade Ibac91d24da2 -> 2217c4222de6\nINFO [alembic.runtime.migration] Running upgrade 2217c4222de6 -> 18a7e90ae768\nINFO [alembic.runtime.migration] Running upgrade 18a7e90ae768 -> e4e236b0e1ff\nINFO [alembic.runtime.migration] Running upgrade e4e236b0e1ff -> e88badaa9591\nINFO [alembic.runtime.migration] Running upgrade e88badaa9591 -> d8bdf05313f4\nINFO [alembic.runtime.migration] Running upgrade d8bdf05313f4 -> dfe425060830\nINFO [alembic.runtime.migration] Running upgrade dfe425060830 -> fd6107509ccd\nINFO [alembic.runtime.migration] Running upgrade fd6107509ccd -> 1ea5dab0897a\nINFO [alembic.runtime.migration] Running upgrade 1ea5dab0897a -> 49d8622c5221\nINFO [alembic.runtime.migration] Running upgrade 49d8622c5221 -> I38991de2b4\nINFO [alembic.runtime.migration] Running upgrade I38991de2b4 -> 532aa95457e2\nINFO [alembic.runtime.migration] Running upgrade 532aa95457e2 -> f010820fc498\nINFO [alembic.runtime.migration] Running upgrade f010820fc498 -> a964d94b4677\nINFO [alembic.runtime.migration] Running upgrade a964d94b4677 -> 26d1e9f5c766\nINFO [alembic.runtime.migration] Running upgrade 26d1e9f5c766 -> 1e0744e4ffea\nINFO [alembic.runtime.migration] Running upgrade 1e0744e4ffea -> 6135a7bd4425\nINFO [alembic.runtime.migration] Running upgrade 6135a7bd4425 -> 8df53b0d2c0e\nINFO [alembic.runtime.migration] Running upgrade 8df53b0d2c0e -> 1bb3393de75d, add qos policy rule Packet Rate Limit\nINFO [alembic.runtime.migration] Running upgrade 1bb3393de75d -> c181bb1d89e4\nINFO [alembic.runtime.migration] Running upgrade c181bb1d89e4 -> ba859d649675\nINFO [alembic.runtime.migration] Running upgrade ba859d649675 -> e981acd076d3\nINFO [alembic.runtime.migration] Running upgrade e981acd076d3 -> 76df7844a8c6, add Local IP tables\nINFO [alembic.runtime.migration] Running upgrade 76df7844a8c6 -> 1ffef8d6f371, migrate RBAC registers from \"target_tenant\" to \"target_project\"\nINFO [alembic.runtime.migration] Running upgrade 1ffef8d6f371 -> 8160f7a9cebb, drop portbindingports table\nINFO [alembic.runtime.migration] Running upgrade 8160f7a9cebb -> cd9ef14ccf87\nINFO [alembic.runtime.migration] Running upgrade cd9ef14ccf87 -> 34cf8b009713\nINFO [alembic.runtime.migration] Running upgrade 34cf8b009713 -> I43e0b669096\nINFO [alembic.runtime.migration] Running upgrade I43e0b669096 -> 4e6e655746f6\nINFO [alembic.runtime.migration] Running upgrade 4e6e655746f6 -> 659cbedf30a1\nINFO [alembic.runtime.migration] Running upgrade 659cbedf30a1 -> 21ff98fabab1\nINFO [alembic.runtime.migration] Running upgrade 21ff98fabab1 -> 5881373af7f5\nINFO [alembic.runtime.migration] Running upgrade 5881373af7f5 -> fc153938cdc1\nINFO [alembic.runtime.migration] Running upgrade fc153938cdc1 -> 93f394357a27\nINFO [alembic.runtime.migration] Running upgrade 93f394357a27 -> 6f1145bff34c\nINFO [alembic.runtime.migration] Running upgrade 6f1145bff34c -> 682c319773d7\nINFO [alembic.runtime.migration] Running upgrade 682c319773d7 -> 0aefee21cd87\nINFO [alembic.runtime.migration] Running upgrade 0aefee21cd87 -> b1199a3adbef\nINFO [alembic.runtime.migration] Running upgrade b1199a3adbef -> c33da356b165\nINFO [alembic.runtime.migration] Running upgrade c33da356b165 -> 89c58a70ceba\nINFO [alembic.runtime.migration] Running upgrade 89c58a70ceba -> 054e34dbe6b4\nINFO [alembic.runtime.migration] Running upgrade 054e34dbe6b4 -> 0e6eff810791\nINFO [alembic.runtime.migration] Running upgrade 0e6eff810791 -> 175fa80908e1\nINFO [alembic.runtime.migration] Running upgrade 175fa80908e1 -> 5bcb7b31ec7d\nINFO [alembic.runtime.migration] Running upgrade 5bcb7b31ec7d -> ad80a9f07c5c\nINFO [alembic.runtime.migration] Running upgrade 7d9d8eeec6ad -> a8b517cff8ab\nINFO [alembic.runtime.migration] Running upgrade a8b517cff8ab -> 3b935b28e7a0\nINFO [alembic.runtime.migration] Running upgrade 3b935b28e7a0 -> b12a3ef66e62\nINFO [alembic.runtime.migration] Running upgrade b12a3ef66e62 -> 97c25b0d2353\nINFO [alembic.runtime.migration] Running upgrade 97c25b0d2353 -> 2e0d7a8a1586\nINFO [alembic.runtime.migration] Running upgrade 2e0d7a8a1586 -> 5c85685d616d\n+++ [[ -n 0 ]]\n+++ for service in ${NEUTRON_BOOTSTRAP_SERVICES}\n+++ neutron-db-manage --subproject vmware-nsx upgrade head\nargument --subproject: Invalid String(choices=['networking-sfc', 'neutron-dynamic-routing', 'neutron-fwaas', 'neutron-vpnaas', 'neutron', 'tap-as-a-service']) value: vmware-nsx\n", "stderr_lines": ["+ sudo -E kolla_set_configs", "2026-01-06 12:53:23.464 INFO Loading config file at /var/lib/kolla/config_files/config.json", "2026-01-06 12:53:23.465 INFO Validating config file", "2026-01-06 12:53:23.465 INFO Kolla config strategy set to: COPY_ALWAYS", "2026-01-06 12:53:23.476 INFO Copying service configuration files", "2026-01-06 12:53:23.476 INFO Copying /var/lib/kolla/config_files/neutron.conf to /etc/neutron/neutron.conf", "2026-01-06 12:53:23.489 INFO Setting permission for /etc/neutron/neutron.conf", "2026-01-06 12:53:23.501 INFO Copying /var/lib/kolla/config_files/nsx.ini to /etc/neutron/plugins/vmware/nsx.ini", "2026-01-06 12:53:23.501 INFO Setting permission for /etc/neutron/plugins/vmware/nsx.ini", "2026-01-06 12:53:23.502 INFO Copying /var/lib/kolla/config_files/ml2_conf.ini to /etc/neutron/plugins/ml2/ml2_conf.ini", "2026-01-06 12:53:23.512 INFO Setting permission for /etc/neutron/plugins/ml2/ml2_conf.ini", "2026-01-06 12:53:23.523 INFO Copying /var/lib/kolla/config_files/id_rsa to /var/lib/neutron/.ssh/id_rsa", "2026-01-06 12:53:23.524 INFO Setting permission for /var/lib/neutron/.ssh/id_rsa", "2026-01-06 12:53:23.524 INFO Writing out command to execute", "++ cat /run_command", "+ CMD='neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/vmware/nsx.ini '", "+ ARGS=", "+ sudo kolla_copy_cacerts", "+ sudo kolla_install_projects", "+ [[ ! -n '' ]]", "+ . kolla_extend_start", "++ [[ ! -d /var/log/kolla/neutron ]]", "++ mkdir -p /var/log/kolla/neutron", "+++ stat -c %a /var/log/kolla/neutron", "++ [[ 2755 != \\7\\5\\5 ]]", "++ chmod 755 /var/log/kolla/neutron", "++ [[ ! ubuntu =~ centos|rocky ]]", "++ /usr/bin/update-alternatives --display iptables", "++ KOLLA_LEGACY_IPTABLES=false", "++ [[ false == \\t\\r\\u\\e ]]", "++ sudo /usr/bin/update-alternatives --auto iptables", "++ sudo /usr/bin/update-alternatives --auto ip6tables", "++ . /usr/local/bin/kolla_neutron_extend_start", "+++ [[ -n 0 ]]", "+++ neutron-db-manage --subproject neutron upgrade head", "INFO [alembic.runtime.migration] Context impl MySQLImpl.", "INFO [alembic.runtime.migration] Will assume non-transactional DDL.", "INFO [alembic.runtime.migration] Context impl MySQLImpl.", "INFO [alembic.runtime.migration] Will assume non-transactional DDL.", "INFO [alembic.runtime.migration] Running upgrade -> kilo", "INFO [alembic.runtime.migration] Running upgrade kilo -> 354db87e3225", "INFO [alembic.runtime.migration] Running upgrade 354db87e3225 -> 599c6a226151", "INFO [alembic.runtime.migration] Running upgrade 599c6a226151 -> 52c5312f6baf", "INFO [alembic.runtime.migration] Running upgrade 52c5312f6baf -> 313373c0ffee", "INFO [alembic.runtime.migration] Running upgrade 313373c0ffee -> 8675309a5c4f", "INFO [alembic.runtime.migration] Running upgrade 8675309a5c4f -> 45f955889773", "INFO [alembic.runtime.migration] Running upgrade 45f955889773 -> 26c371498592", "INFO [alembic.runtime.migration] Running upgrade 26c371498592 -> 1c844d1677f7", "INFO [alembic.runtime.migration] Running upgrade 1c844d1677f7 -> 1b4c6e320f79", "INFO [alembic.runtime.migration] Running upgrade 1b4c6e320f79 -> 48153cb5f051", "INFO [alembic.runtime.migration] Running upgrade 48153cb5f051 -> 9859ac9c136", "INFO [alembic.runtime.migration] Running upgrade 9859ac9c136 -> 34af2b5c5a59", "INFO [alembic.runtime.migration] Running upgrade 34af2b5c5a59 -> 59cb5b6cf4d", "INFO [alembic.runtime.migration] Running upgrade 59cb5b6cf4d -> 13cfb89f881a", "INFO [alembic.runtime.migration] Running upgrade 13cfb89f881a -> 32e5974ada25", "INFO [alembic.runtime.migration] Running upgrade 32e5974ada25 -> ec7fcfbf72ee", "INFO [alembic.runtime.migration] Running upgrade ec7fcfbf72ee -> dce3ec7a25c9", "INFO [alembic.runtime.migration] Running upgrade dce3ec7a25c9 -> c3a73f615e4", "INFO [alembic.runtime.migration] Running upgrade c3a73f615e4 -> 659bf3d90664", "INFO [alembic.runtime.migration] Running upgrade 659bf3d90664 -> 1df244e556f5", "INFO [alembic.runtime.migration] Running upgrade 1df244e556f5 -> 19f26505c74f", "INFO [alembic.runtime.migration] Running upgrade 19f26505c74f -> 15be73214821", "INFO [alembic.runtime.migration] Running upgrade 15be73214821 -> b4caf27aae4", "INFO [alembic.runtime.migration] Running upgrade b4caf27aae4 -> 15e43b934f81", "INFO [alembic.runtime.migration] Running upgrade 15e43b934f81 -> 31ed664953e6", "INFO [alembic.runtime.migration] Running upgrade 31ed664953e6 -> 2f9e956e7532", "INFO [alembic.runtime.migration] Running upgrade 2f9e956e7532 -> 3894bccad37f", "INFO [alembic.runtime.migration] Running upgrade 3894bccad37f -> 0e66c5227a8a", "INFO [alembic.runtime.migration] Running upgrade 0e66c5227a8a -> 45f8dd33480b", "INFO [alembic.runtime.migration] Running upgrade 45f8dd33480b -> 5abc0278ca73", "INFO [alembic.runtime.migration] Running upgrade 5abc0278ca73 -> d3435b514502", "INFO [alembic.runtime.migration] Running upgrade d3435b514502 -> 30107ab6a3ee", "INFO [alembic.runtime.migration] Running upgrade 30107ab6a3ee -> c415aab1c048", "INFO [alembic.runtime.migration] Running upgrade c415aab1c048 -> a963b38d82f4", "INFO [alembic.runtime.migration] Running upgrade kilo -> 30018084ec99", "INFO [alembic.runtime.migration] Running upgrade 30018084ec99 -> 4ffceebfada", "INFO [alembic.runtime.migration] Running upgrade 4ffceebfada -> 5498d17be016", "INFO [alembic.runtime.migration] Running upgrade 5498d17be016 -> 2a16083502f3", "INFO [alembic.runtime.migration] Running upgrade 2a16083502f3 -> 2e5352a0ad4d", "INFO [alembic.runtime.migration] Running upgrade 2e5352a0ad4d -> 11926bcfe72d", "INFO [alembic.runtime.migration] Running upgrade 11926bcfe72d -> 4af11ca47297", "INFO [alembic.runtime.migration] Running upgrade 4af11ca47297 -> 1b294093239c", "INFO [alembic.runtime.migration] Running upgrade 1b294093239c -> 8a6d8bdae39", "INFO [alembic.runtime.migration] Running upgrade 8a6d8bdae39 -> 2b4c2465d44b", "INFO [alembic.runtime.migration] Running upgrade 2b4c2465d44b -> e3278ee65050", "INFO [alembic.runtime.migration] Running upgrade e3278ee65050 -> c6c112992c9", "INFO [alembic.runtime.migration] Running upgrade c6c112992c9 -> 5ffceebfada", "INFO [alembic.runtime.migration] Running upgrade 5ffceebfada -> 4ffceebfcdc", "INFO [alembic.runtime.migration] Running upgrade 4ffceebfcdc -> 7bbb25278f53", "INFO [alembic.runtime.migration] Running upgrade 7bbb25278f53 -> 89ab9a816d70", "INFO [alembic.runtime.migration] Running upgrade 89ab9a816d70 -> c879c5e1ee90", "INFO [alembic.runtime.migration] Running upgrade c879c5e1ee90 -> 8fd3918ef6f4", "INFO [alembic.runtime.migration] Running upgrade 8fd3918ef6f4 -> 4bcd4df1f426", "INFO [alembic.runtime.migration] Running upgrade 4bcd4df1f426 -> b67e765a3524", "INFO [alembic.runtime.migration] Running upgrade a963b38d82f4 -> 3d0e74aa7d37", "INFO [alembic.runtime.migration] Running upgrade 3d0e74aa7d37 -> 030a959ceafa", "INFO [alembic.runtime.migration] Running upgrade 030a959ceafa -> a5648cfeeadf", "INFO [alembic.runtime.migration] Running upgrade a5648cfeeadf -> 0f5bef0f87d4", "INFO [alembic.runtime.migration] Running upgrade 0f5bef0f87d4 -> 67daae611b6e", "INFO [alembic.runtime.migration] Running upgrade b67e765a3524 -> a84ccf28f06a", "INFO [alembic.runtime.migration] Running upgrade a84ccf28f06a -> 7d9d8eeec6ad", "INFO [alembic.runtime.migration] Running upgrade 67daae611b6e -> 6b461a21bcfc", "INFO [alembic.runtime.migration] Running upgrade 6b461a21bcfc -> 5cd92597d11d", "INFO [alembic.runtime.migration] Running upgrade 5cd92597d11d -> 929c968efe70", "INFO [alembic.runtime.migration] Running upgrade 929c968efe70 -> a9c43481023c", "INFO [alembic.runtime.migration] Running upgrade a9c43481023c -> 804a3c76314c", "INFO [alembic.runtime.migration] Running upgrade 804a3c76314c -> 2b42d90729da", "INFO [alembic.runtime.migration] Running upgrade 2b42d90729da -> 62c781cb6192", "INFO [alembic.runtime.migration] Running upgrade 62c781cb6192 -> c8c222d42aa9", "INFO [alembic.runtime.migration] Running upgrade c8c222d42aa9 -> 349b6fd605a6", "INFO [alembic.runtime.migration] Running upgrade 349b6fd605a6 -> 7d32f979895f", "INFO [alembic.runtime.migration] Running upgrade 7d32f979895f -> 594422d373ee", "INFO [alembic.runtime.migration] Running upgrade 594422d373ee -> 61663558142c", "INFO [alembic.runtime.migration] Running upgrade 61663558142c -> 867d39095bf4, port forwarding", "INFO [alembic.runtime.migration] Running upgrade 867d39095bf4 -> d72db3e25539, modify uniq port forwarding", "INFO [alembic.runtime.migration] Running upgrade d72db3e25539 -> cada2437bf41", "INFO [alembic.runtime.migration] Running upgrade cada2437bf41 -> 195176fb410d, router gateway IP QoS", "INFO [alembic.runtime.migration] Running upgrade 195176fb410d -> fb0167bd9639", "INFO [alembic.runtime.migration] Running upgrade fb0167bd9639 -> 0ff9e3881597", "INFO [alembic.runtime.migration] Running upgrade 0ff9e3881597 -> 9bfad3f1e780", "INFO [alembic.runtime.migration] Running upgrade 9bfad3f1e780 -> 63fd95af7dcd", "INFO [alembic.runtime.migration] Running upgrade 63fd95af7dcd -> c613d0b82681", "INFO [alembic.runtime.migration] Running upgrade c613d0b82681 -> c3e9d13c4367", "INFO [alembic.runtime.migration] Running upgrade c3e9d13c4367 -> 86274d77933e", "INFO [alembic.runtime.migration] Running upgrade 86274d77933e -> f4b9654dd40c", "INFO [alembic.runtime.migration] Running upgrade f4b9654dd40c -> a010322604bc", "INFO [alembic.runtime.migration] Running upgrade a010322604bc -> 263d454a9655", "INFO [alembic.runtime.migration] Running upgrade 263d454a9655 -> Ibac91d24da2", "INFO [alembic.runtime.migration] Running upgrade Ibac91d24da2 -> 2217c4222de6", "INFO [alembic.runtime.migration] Running upgrade 2217c4222de6 -> 18a7e90ae768", "INFO [alembic.runtime.migration] Running upgrade 18a7e90ae768 -> e4e236b0e1ff", "INFO [alembic.runtime.migration] Running upgrade e4e236b0e1ff -> e88badaa9591", "INFO [alembic.runtime.migration] Running upgrade e88badaa9591 -> d8bdf05313f4", "INFO [alembic.runtime.migration] Running upgrade d8bdf05313f4 -> dfe425060830", "INFO [alembic.runtime.migration] Running upgrade dfe425060830 -> fd6107509ccd", "INFO [alembic.runtime.migration] Running upgrade fd6107509ccd -> 1ea5dab0897a", "INFO [alembic.runtime.migration] Running upgrade 1ea5dab0897a -> 49d8622c5221", "INFO [alembic.runtime.migration] Running upgrade 49d8622c5221 -> I38991de2b4", "INFO [alembic.runtime.migration] Running upgrade I38991de2b4 -> 532aa95457e2", "INFO [alembic.runtime.migration] Running upgrade 532aa95457e2 -> f010820fc498", "INFO [alembic.runtime.migration] Running upgrade f010820fc498 -> a964d94b4677", "INFO [alembic.runtime.migration] Running upgrade a964d94b4677 -> 26d1e9f5c766", "INFO [alembic.runtime.migration] Running upgrade 26d1e9f5c766 -> 1e0744e4ffea", "INFO [alembic.runtime.migration] Running upgrade 1e0744e4ffea -> 6135a7bd4425", "INFO [alembic.runtime.migration] Running upgrade 6135a7bd4425 -> 8df53b0d2c0e", "INFO [alembic.runtime.migration] Running upgrade 8df53b0d2c0e -> 1bb3393de75d, add qos policy rule Packet Rate Limit", "INFO [alembic.runtime.migration] Running upgrade 1bb3393de75d -> c181bb1d89e4", "INFO [alembic.runtime.migration] Running upgrade c181bb1d89e4 -> ba859d649675", "INFO [alembic.runtime.migration] Running upgrade ba859d649675 -> e981acd076d3", "INFO [alembic.runtime.migration] Running upgrade e981acd076d3 -> 76df7844a8c6, add Local IP tables", "INFO [alembic.runtime.migration] Running upgrade 76df7844a8c6 -> 1ffef8d6f371, migrate RBAC registers from \"target_tenant\" to \"target_project\"", "INFO [alembic.runtime.migration] Running upgrade 1ffef8d6f371 -> 8160f7a9cebb, drop portbindingports table", "INFO [alembic.runtime.migration] Running upgrade 8160f7a9cebb -> cd9ef14ccf87", "INFO [alembic.runtime.migration] Running upgrade cd9ef14ccf87 -> 34cf8b009713", "INFO [alembic.runtime.migration] Running upgrade 34cf8b009713 -> I43e0b669096", "INFO [alembic.runtime.migration] Running upgrade I43e0b669096 -> 4e6e655746f6", "INFO [alembic.runtime.migration] Running upgrade 4e6e655746f6 -> 659cbedf30a1", "INFO [alembic.runtime.migration] Running upgrade 659cbedf30a1 -> 21ff98fabab1", "INFO [alembic.runtime.migration] Running upgrade 21ff98fabab1 -> 5881373af7f5", "INFO [alembic.runtime.migration] Running upgrade 5881373af7f5 -> fc153938cdc1", "INFO [alembic.runtime.migration] Running upgrade fc153938cdc1 -> 93f394357a27", "INFO [alembic.runtime.migration] Running upgrade 93f394357a27 -> 6f1145bff34c", "INFO [alembic.runtime.migration] Running upgrade 6f1145bff34c -> 682c319773d7", "INFO [alembic.runtime.migration] Running upgrade 682c319773d7 -> 0aefee21cd87", "INFO [alembic.runtime.migration] Running upgrade 0aefee21cd87 -> b1199a3adbef", "INFO [alembic.runtime.migration] Running upgrade b1199a3adbef -> c33da356b165", "INFO [alembic.runtime.migration] Running upgrade c33da356b165 -> 89c58a70ceba", "INFO [alembic.runtime.migration] Running upgrade 89c58a70ceba -> 054e34dbe6b4", "INFO [alembic.runtime.migration] Running upgrade 054e34dbe6b4 -> 0e6eff810791", "INFO [alembic.runtime.migration] Running upgrade 0e6eff810791 -> 175fa80908e1", "INFO [alembic.runtime.migration] Running upgrade 175fa80908e1 -> 5bcb7b31ec7d", "INFO [alembic.runtime.migration] Running upgrade 5bcb7b31ec7d -> ad80a9f07c5c", "INFO [alembic.runtime.migration] Running upgrade 7d9d8eeec6ad -> a8b517cff8ab", "INFO [alembic.runtime.migration] Running upgrade a8b517cff8ab -> 3b935b28e7a0", "INFO [alembic.runtime.migration] Running upgrade 3b935b28e7a0 -> b12a3ef66e62", "INFO [alembic.runtime.migration] Running upgrade b12a3ef66e62 -> 97c25b0d2353", "INFO [alembic.runtime.migration] Running upgrade 97c25b0d2353 -> 2e0d7a8a1586", "INFO [alembic.runtime.migration] Running upgrade 2e0d7a8a1586 -> 5c85685d616d", "+++ [[ -n 0 ]]", "+++ for service in ${NEUTRON_BOOTSTRAP_SERVICES}", "+++ neutron-db-manage --subproject vmware-nsx upgrade head", "argument --subproject: Invalid String(choices=['networking-sfc', 'neutron-dynamic-routing', 'neutron-fwaas', 'neutron-vpnaas', 'neutron', 'tap-as-a-service']) value: vmware-nsx"], "stdout": "iptables - auto mode\n link best version is /usr/sbin/iptables-nft\n link currently points to /usr/sbin/iptables-nft\n link iptables is /usr/sbin/iptables\n slave iptables-restore is /usr/sbin/iptables-restore\n slave iptables-save is /usr/sbin/iptables-save\n/usr/sbin/iptables-legacy - priority 10\n slave iptables-restore: /usr/sbin/iptables-legacy-restore\n slave iptables-save: /usr/sbin/iptables-legacy-save\n/usr/sbin/iptables-nft - priority 20\n slave iptables-restore: /usr/sbin/iptables-nft-restore\n slave iptables-save: /usr/sbin/iptables-nft-save\nRunning upgrade for neutron ...\nOK\n", "stdout_lines": ["iptables - auto mode", " link best version is /usr/sbin/iptables-nft", " link currently points to /usr/sbin/iptables-nft", " link iptables is /usr/sbin/iptables", " slave iptables-restore is /usr/sbin/iptables-restore", " slave iptables-save is /usr/sbin/iptables-save", "/usr/sbin/iptables-legacy - priority 10", " slave iptables-restore: /usr/sbin/iptables-legacy-restore", " slave iptables-save: /usr/sbin/iptables-legacy-save", "/usr/sbin/iptables-nft - priority 20", " slave iptables-restore: /usr/sbin/iptables-nft-restore", " slave iptables-save: /usr/sbin/iptables-nft-save", "Running upgrade for neutron ...", "OK"]} whats the problem ?

2 3

[tc][all] No weekly IRC meeting on January 6 2026
by Goutham Pacha Ravi 06 Jan '26

06 Jan '26

Hello Stackers, A number of TC members are still out on PTO or observing public holidays in their respective countries, so we’ll be skipping the weekly IRC meeting this week, and the next meeting will be on January 13th 2026 at 1700 UTC in OFTC’s #openstack-tc channel. Thank you, Goutham Pacha Ravi (gouthamr) Openstack TC Chair

1 0

[openstacksdk][keystoneauth1][nova] Memory leak in nova-scheduler, possibly all services?
by Clippinger, Sam 05 Jan '26

05 Jan '26

Hello everyone, We've been seeing steady memory leaks in some of our OpenStack API services. I think I've found the cause but I'd appreciate some feedback. When a service creates a client object (e.g. placementclient) to use another service's API, the call goes through Proxy.request() in the openstacksdk module. That function calls _report_stats()[1] for every request which calls three other functions for statsd, prometheus and influxdb. The prometheus function records the number of requests and response times in a dict using the full URL of the request.[2] This data is recorded unless the _prometheus_counter or _prometheus_histogram member variables are None.[2] Those member variables are set by config.CloudRegion.get_prometheus_counter()[3] and config.CloudRegion.get_prometheus_histogram()[4], which do not check any config settings. It looks like the only way to prevent this behavior is to uninstall the prometheus_client module.[5] Unfortunately prometheus_client is required by oslo.metrics[6] which is required by oslo.messaging[7]. This is causing a lot of extra memory usage in our production environments. It's worst in our build farm where we create over 500K VMs per week. nova-scheduler queries a lot of unique URLs because the Placement API uses the VM's UUID to get allocations[8] and each URL gets its own counter and histogram. Even though we run 6 copies of nova-scheduler (currently Caracal) after a few weeks each copy will reach 8 GB and the worker processes will start getting OOMkilled, putting the new VM in error state. The nova-scheduler parent process keeps running and restarts the workers, which just keep getting killed and VMs can't be reliably scheduled until nova-scheduler is restarted. This feels like two problems to me. We don't need Prometheus metrics from the OpenStack services but there's no way to turn them off. The Session class in keystoneauth1 supports a collect-timing option[9] (default False) but it's only used in one or two places that I can find. The CloudRegion methods get their config from the Adapter[10] class in keystoneauth1, which does not support collect-timing. Should it? Even if we did use these Prometheus metrics, it seems like they shouldn't be allowed to grow unbounded forever. Should the Proxy._report_stats_prometheus() function[2] limit the metrics by age or quantity? Any thoughts? I've patched our services in-house to turn off these metrics (I'll have results in a week). In the meantime, are we doing something wrong or is every OpenStack service always collecting these metrics constantly? -- Sam Clippinger 1: https://github.com/openstack/openstacksdk/blob/stable/2025.2/openstack/prox… 2: https://github.com/openstack/openstacksdk/blob/stable/2025.2/openstack/prox… 3: https://github.com/openstack/openstacksdk/blob/stable/2025.2/openstack/conf… 4: https://github.com/openstack/openstacksdk/blob/stable/2025.2/openstack/conf… 5: https://github.com/openstack/openstacksdk/blob/stable/2025.2/openstack/conf… 6: https://github.com/openstack/oslo.metrics/blob/stable/2025.2/requirements.t… 7: https://github.com/openstack/oslo.messaging/blob/stable/2025.2/requirements… 8: https://docs.openstack.org/api-ref/placement/#list-allocations 9: https://github.com/openstack/keystoneauth/blob/stable/2025.2/keystoneauth1/… 10: https://github.com/openstack/keystoneauth/blob/stable/2025.2/keystoneauth1/… ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

4 4

[puppet-cinder,glance,manila] Resigning from core team
by Alan Bishop 05 Jan '26

05 Jan '26

Hello, Due to a change in my work status, I am no longer able to fulfill my obligations as a core reviewer. With this in mind, I am resigning from the core team on the puppet-cinder, puppet-glance and puppet-manila projects. Alan Bishop

3 2

[release] Release countdown for week R-12, Jan 05 - Jan 09
by Elõd Illés 05 Jan '26

05 Jan '26

Development Focus ----------------- The Gazpacho-2 milestone is *this* week, on January 8th, 2026! 2026.1 Gazpacho-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/gazpacho/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Today, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. This week is also the deadline to freeze the contents of the final release. All new '2026.1 Gazpacho' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables/gazpa… and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in 2026.1 Gazpacho have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in 2026.1 Gazpacho, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Gazpacho-2 Milestone: January 8th, 2026 Előd Illés irc: elodilles @ #openstack-release

1 0

[Keystone][ldap] Keystone bind request to ldap not able to interpret if the user's password is expired.
by Sharath Ck 05 Jan '26

05 Jan '26

Hi, I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set to true. However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed? Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response. P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked. user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true Regards, Sharath

3 2

[ops][cinder][show-and-tell] I wrote an open-source tool to automate OpenStack Cinder snapshot lifecycles
by aravindhstanley＠gmail.com 05 Jan '26

05 Jan '26

Hello folks, We have been using OpenStack for a while and needed a reliable way to keep snapshots on hot storage for compliance and quick recovery. While Cinder provides the mechanism to create snapshots, the actual scheduling and rotation are largely left for the operator to figure out. I know there are robust commercial tools like Trilio (awesome tool, by the way), but I wanted a lightweight, open-source alternative to manage the snapshot lifecycle without the extra overhead. So, I built SnapSentry. It is written in Go, completely free, and MIT licensed, so I thought I should share it with the community. Key Features: Metadata-Driven: No central database or config files; just tag your volumes with metadata and it works. (Helper command takes care of metadata updates) Atomic-ish VM Snapshots: Automatically identifies all volumes attached to a specific VM and snapshots them in parallel to minimize consistency gaps. Smart Concurrency: Uses a hybrid model (Parallel for attached volumes, Sequential for unattached) to prevent API throttling. Resilient: Handles transient OpenStack errors (500s) and cleans up orphaned "zombie" snapshots automatically. Secure: Supports restricted Application Credentials for least-privilege operation. Here is the repo: https://github.com/aravindh-murugesan/openstack-snapsentry-go Cheers, and feedback is welcome! Note: I do use AI assistant for docs, but the logic or the app itself is not vibe-coded. I'm not sure if this is the right place to post this, if it's not, I apologize. Just trying to contribute to the openstack ecosystem :)

2 1

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 04 Jan '26

04 Jan '26

Hi team, Sorry for the late notice. I'd like to cancel the IRC meeting today as we agreed in the previous meeting. Regards, Yasufumi

1 0

[Opensource Tool] Cinder snapshot lifecycle management
by Aravindh M 03 Jan '26

03 Jan '26

Hello folks, We have been using OpenStack for a while and needed a reliable way to keep snapshots on hot storage for compliance and quick recovery. While Cinder provides the mechanism to create snapshots, the actual scheduling and rotation are largely left for the operator to figure out. I know there are robust commercial tools like Trilio (awesome tool, by the way), but I wanted a lightweight, open-source alternative to manage the snapshot lifecycle without the extra overhead. So, I built *SnapSentry*. It is written in Go, completely free, and MIT licensed, so I thought I should share it with the community. *Key Features:* - *Metadata-Driven:* No central database or config files; just tag your volumes with metadata and it works. (Helper command takes care of metadata updates) - *Atomic-ish VM Snapshots:* Automatically identifies all volumes attached to a specific VM and snapshots them in parallel to minimize consistency gaps. - *Smart Concurrency:* Uses a hybrid model (Parallel for attached volumes, Sequential for unattached) to prevent API throttling. - *Resilient:* Handles transient OpenStack errors (500s) and cleans up orphaned "zombie" snapshots automatically. - *Secure:* Supports restricted Application Credentials for least-privilege operation. Here is the repo: https://github.com/aravindh-murugesan/openstack-snapsentry-go Cheers, and feedback is welcome! Note: I do use AI assistant for docs, but the logic or the app itself is not vibe-coded. I'm not sure if this is the right place to post this, if it's not, I apologize. Just trying to contribute to the openstack ecosystem :)

1 0

[neutron] bug deputy report for week of 2025-12-15
by Bence Romsics 02 Jan '26

02 Jan '26

Hi Team, Here's the deputy report for the week of 2025-12-15. Sorry for being so slow! High: * https://bugs.launchpad.net/neutron/+bug/2136827 Functional tests using SqlFixture are extremely slow fix in progress: https://review.opendev.org/c/openstack/neutron/+/971472 * https://bugs.launchpad.net/neutron/+bug/2136733 The highest priority chassis gateway port fails to bind after chassis was restarted/crashed wip fix: https://review.opendev.org/c/openstack/neutron/+/971876 Medium: * https://bugs.launchpad.net/neutron/+bug/2136747 [FT] "ResourceWarning: unclosed file" errors in the FT execution unassigned, but Jakub investigated a bit * https://bugs.launchpad.net/neutron/+bug/2136147 test_two_vms_fips test has very specific expectations from availability zones fix in progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/970865 * https://bugs.launchpad.net/neutron/+bug/2136864 [ovn-db-sync] sync_hostname_and_physical_networks is expecting to find Chassis among agents fix in progress: https://review.opendev.org/c/openstack/neutron/+/971527 Incomplete: * https://bugs.launchpad.net/neutron/+bug/2136466 [rbac] Unexpected behaviour on floating ip port forwarding list Regards, Bence

1 0