- openstack-discuss - lists.openstack.org

[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