[I've dropped the cross-posting for other lists.] On 2026-03-06 15:18:25 +0100 (+0100), Dmitriy Rabotyagov wrote:

From my perspective, I am less concerned about the RDO itself, but more about rdo-deps. As, from what I know, rdo-deps sometimes are the only source of some dependencies, which are required for services. Good example of that is liberasurecode, which is required by Swift, and can be hardly found elsewhere. I believe there are more examples of that, but this is what I can recall right away.

Ideally, it would be nice to have some kind of SIG, or offload these packages to respective SIGs (like liberasurecode could be by Storage SIG potentially). [...]

There's still a "Packaging SIG" listed as active at https://governance.openstack.org/sigs/ with the description: To make OpenStack easier to update and consume by operators and provide tooling to package all OpenStack projects directly for (at first) all RPM based distributions. According to governance, it's responsible for the following projects in OpenDev: openstack/rpm-packaging openstack/rpm-packaging-tools openstack/pymod2pkg openstack/renderspec Perhaps that would be a good place to coordinate (and revive if necessary)? -- Jeremy Stanley

Hi all, Apologies for the delayed response - I was away and am just catching up on this important discussion. Thank you for the thoughtful conversation and the strong response to Francesco's call for volunteers. It's encouraging to see 16+ people sign up on the etherpad [0], representing organizations like Rocky Linux, OSUOSL, CERN, INFN, CSC Finland, and others. We're excited by the community interest and are reviewing the requests to help bootstrap the effort. Addressing the Outstanding Questions: 1. Epoxy lifecycle support - There will be no further updates to Epoxy RPMs unless the community picks up maintenance. This has been the case since the initial call for volunteers over a year ago. There also won’t be any rpms for any newer releases including Hibiscus. The current intent is to provide Source-to-Image containers for Hibiscus, though that’s not mutually exclusive. 2. Client libraries - No updates are planned for EL10 client packages unless community volunteers take this on. 3. rdo-deps dependencies - The fate of rdo-deps (packages like liberasurecode) requires more investigation. We understand these are critical for several services and will follow up on this. 4. Mentorship and resources - We're actively reviewing what support Red Hat can provide to help bootstrap volunteer efforts. We'll follow up as we have more clarity here. 5. Scope and timeline - The volunteer group will need to define a sustainable scope based on Alfredo's breakdown (248 packages + 400 deps) and available capacity. Next Steps: - Schedule a meeting with volunteers to discuss scope and expectations - Follow up on rdo-deps situation - Follow up on what bootstrap support we can provide - Work with the volunteer group to define realistic scope and ownership Thank you to everyone who's volunteered. This level of community engagement is encouraging, and we hope it leads to a sustainable path forward for OpenStack RPM packaging. Best regards, Mike [0] https://etherpad.opendev.org/p/rdo-volunteers On Fri, Mar 6, 2026 at 9:18 AM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

Hey,

From my perspective, I am less concerned about the RDO itself, but more about rdo-deps. As, from what I know, rdo-deps sometimes are the only source of some dependencies, which are required for services. Good example of that is liberasurecode, which is required by Swift, and can be hardly found elsewhere. I believe there are more examples of that, but this is what I can recall right away.

Ideally, it would be nice to have some kind of SIG, or offload these packages to respective SIGs (like liberasurecode could be by Storage SIG potentially).

чт, 5 мар. 2026 г. в 18:33, Jose Castro Leon <jose.castro.leon@cern.ch>:

...

We are also heavily affected by this change, as all our deployments at CERN rely on it. Moreover, we are early adopters of RDO and now that we are getting into Epoxy release, it just slips away. The deployment model is not something you can easily change.

Does it also mean that our el10 users may never have client libraries packaged to use our setups?

And following Massimo remark, will the repo be maintained while it's still in supported status in OpenStack? If not, are you implying that we also need to repackage future security updates?

Thanks, Jose CERN Cloud Team

------------------------------ *From:* Massimo Sgaravatto <massimo.sgaravatto@gmail.com> *Sent:* Thursday, March 5, 2026 1:40 PM *To:* Amy Marrich <amy@demarco.com> *Cc:* RDO Developmen List <dev@lists.rdoproject.org>; openstack-discuss < openstack-discuss@lists.openstack.org>; users@lists.rdoproject.org < users@lists.rdoproject.org>; Mike Burns <mburns@redhat.com> *Subject:* Re: Update on RDO: A Shift to Containers

A non-negligible impact for our deployment :-(

So, as far as I understand, no rpms will be released for the F and G releases, correct?

Will you keep releasing updated RPMs for the Epoxy release, while it is in the maintained status, or the repo

https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ will not be updated anymore ?

Thanks, Massimo

On Wed, Mar 4, 2026 at 4:19 PM Amy Marrich <amy@demarco.com> wrote:

Dear RDO Community/Stakeholders,

This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered.

End of RDO RPM Builds

Historically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release.

Introducing the New RDO: Container Focus

The future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers.

RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the <http://github.com/openstack-k8s-operators> github.com/openstack-k8s-operators organization, and these new container builds will essentially be the "new RDO".

Timeline and Usage:

-

This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined. -

These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization. -

While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators. -

Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform.

Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward.

Sincerely,

Amy