12:16 p.m.
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(a)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(a)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(a)gmail.com>
> *Sent:* Thursday, March 5, 2026 1:40 PM
> *To:* Amy Marrich <amy(a)demarco.com>
> *Cc:* RDO Developmen List <dev(a)lists.rdoproject.org>; openstack-discuss <
> openstack-discuss(a)lists.openstack.org>; users(a)lists.rdoproject.org <
> users(a)lists.rdoproject.org>; Mike Burns <mburns(a)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(a)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
>
>