On 29/01/2026 21:46, Goutham Pacha Ravi wrote:
Hi Sean, On Thu, Jan 29, 2026 at 10:30 AM Sean Mooney <smooney@redhat.com> wrote:
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
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
maintenance try and
restart Cyborg development in a similar way as we did with Watcher.
Thank you for taking on this effort. With the recent changes in the way OpenStack is being put to use, Cyborg's relevance is growing, even if the need for constant project maintenance isn't apparent. Li Liu has kept the project going for the Gazpacho release, but the maintenance team unfortunately decayed due to an organic shift in focus.
The work you've done in reviving Watcher has been very well received. Speaking with my TC hat on, my concern is when the core team is composed primarily of individuals from a single organization. While this is sometimes unavoidable, we have seen how projects like Cyborg can be left in jeopardy when an organization changes tack and moves on from contributing, despite having many users. I am very grateful to the companies and individuals that take on the arduous task of maintaining this software, I want to actively encourage you to seek out diverse maintainers to ensure the project's long-term sustenance.
yes i am hoping that this will reemage as a multi faceded effort form different groups, be it vendors, operators, users or individual contributor im hoping that other will see value in cyborg and want to help build/maintain it. a bus factor of 1 even at the company level is not good for long term sustainability while https://www.openstack.org/openstack-for-ai-white-paper has some interesting future implication for how cyborg could evolve i think are also some interesting data and infra sovereignty elements too. for example there are a lot of traditional workloads like database that just need local high speed storage cyborg is positioned to enable nvme disk management in a multi tenant way supporting classic enterprise business models where a team jsut need a VPS like billing of a "server" with 2 4TB ssds so im hopign we can cater for the classic virtualization usecase as well as the emerging and future uescase for ai, telco and enterprise.
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.
+1 thank you The unmerged bot patches are evidence that we lack maintenance.
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.
this is one of the bigger challenges for cyborg its true that for any project testing is important but by its nature since cyborg manages hardware it is hard to properly test in first party ci. i am hoping with some tricks we will be able to improve the first party testing but this is an area where operators or vendors could help with third-party testing.
++
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.
Thank you for caring about these important details. This is a common labor for all project maintainers and another good indication of a project's health.
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 :)
If Li Liu can make the core team adjustments, that'd be great. If not, the TC can help with seeding the core team as we've done with other projects in the recent past.
For 2026.2, The PTL elections are imminent. If you're still identifying liaisons, I would recommend nominating yourself as PTL for the upcoming release cycle. PTLs can and should have liaisons that can handle different aspects of project maintenance too :) Although I understand that you want to prevent a single-point-of-failure. You could alternatively propose a DPL transition right away with liaisons you do have; but please note that any PTL nominees during the election window will override this change. Please continue to coordinate with other new/existing maintainers and the TC as you're doing. We'll conclude elections by March 19, 2026 at the latest, and we'll resolve the project governance by then.
honestly i am fine with either PTL or DPL models as long as the work gets done and we can spread the load to not have a single point of failure. if for transparency and paper work reason it similar to self nominate for the ptl election and move to DPl or not once we have time to discuss that more widely in terms of liaisons i'm likely to continue as security liaison for watcher next cycle and was going to volunteer for the same role in watcher im happy to pick up either the release or TACT roles as well however my plan was to ask chandan and joan who are both currently release liaison for watcher to both help with that role in cyborg. that way each would be backup for the other and one could focus more on watcher releases while the other focuses more on cyborg.
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.
on this point i also added alex on cc as the other existing core that has been active in the last cycle li liu, alex please let me know if you have any concerns with the proposal to extend the core team and with any of the technical or nontechnical aspects.
+1, added it to our agenda.: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
If there are no objections, I will coordinate with the TC and Infra team regarding the necessary permission updates.
Regards,
Sean