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 <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> >> *Sent:* Thursday, March 5, 2026 1:40 PM >> *To:* Amy Marrich <[email protected]> >> *Cc:* RDO Developmen List <[email protected]>; openstack-discuss < >> [email protected]>; [email protected] < >> [email protected]>; Mike Burns <[email protected]> >> *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 <[email protected]> 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 >> >>
_______________________________________________ dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s To unsubscribe: %(_internal_name)s-unsubscribe@%(host_name)s
