Looking for an RDO alternative without moving OpenStack immediately to containers?
FishOS provides a supported, RPM-based OpenStack path on AlmaLinux. Sardina Systems supports OpenStack Epoxy on AlmaLinux 9 and AlmaLinux 10, and OpenStack Gazpacho on AlmaLinux 10, providing a viable RDO alternative.
Following RDO’s announcement earlier this year that it would no longer publish RPM releases, operators face four broad directions: wait for a community RPM revival, take packaging in-house, adopt a container-based delivery model, or migrate to a supported RPM-based distribution. FishOS provides a turnkey solution for that final path.
The Status Quo for RDO-Based Operators
For many OpenStack operators, RDO has been an important part of how their cloud is built, updated and maintained. It has provided RPM packages for OpenStack in CentOS Stream and Red Hat Enterprise Linux environments.
In March 2026, RDO announced that it would not publish RPM releases after OpenStack Epoxy (2025.1), shifting its remaining project focus entirely to containers. While the RDO community is making ongoing efforts to resume RPM publishing, its future availability and maintenance model remain unpredictable.
For an RDO-based operator, the question is no longer just where to obtain the next package. It is how to maintain a secure, updatable OpenStack environment without taking on unnecessary operational risk.
Four Paths Forward for RDO Operators
The OpenStack ecosystem offers a few solutions. However, the most common alternatives require a material change to how the cloud is delivered and operated.
Option 1: Move to a container-based OpenStack delivery model
In a container-based deployment, OpenStack services are delivered as versioned container images rather than installed as RPM packages directly on the host operating system. Kolla-Ansible is one example: it provides containers and Ansible playbooks for operating OpenStack clouds. Canonical OpenStack, which uses Kubernetes for the control plane, is another.
Note that this refers to how OpenStack services themselves are packaged and operated. It does not necessarily mean replacing virtual-machine workloads with containers.
For some organizations, container-based OpenStack can be the right replacement. However, it introduces a fundamentally different operating model involving image registries, container runtime, and deployment automation. In some architectures, it also requires Kubernetes for the control plane, demanding a review of your team’s container expertise.
Option 2: Move to an Ubuntu and DEB-based ecosystem
Another route is to change the Linux package ecosystem entirely. Ubuntu is Debian-based and uses DEB packages managed with APT, rather than RPM packages managed with DNF/YUM. Ubuntu publishes OpenStack packages through the Ubuntu Cloud Archive (e.g., Epoxy packages for Ubuntu 24.04 LTS).
While this maintains a traditional package-based route, it forces a significant shift away from the familiar Red Hat-style (RPM-based) ecosystem to Ubuntu/DEB tooling. This alters your package management, release combinations, and daily operational practices, requiring your team to adapt to a fundamentally different Linux environment.
Option 3: Adopt an RPM-based FishOS environment on AlmaLinux
For organizations that want to remain in an RPM-based, Red Hat-compatible operating model, FishOS provides a supported path forward.
FishOS is an RPM-based OpenStack distribution running on AlmaLinux. Sardina Systems maintains its own RPM package sets for OpenStack Epoxy and Gazpacho. Epoxy is supported on AlmaLinux 9 and 10, while Gazpacho is supported on AlmaLinux 10.
This gives operators a continuous package-based route across current OpenStack and AlmaLinux generations. Epoxy on AlmaLinux 9 supports established environments, while Gazpacho on AlmaLinux 10 provides a route to the newer OS generation. FishOS combines this familiar foundation with integrated Ceph and Kubernetes capabilities, allowing you to run open infrastructure without being forced to abandon a known operating model.
Option 4: Maintain the current unsupported environment
Some operators may decide not to change their cloud immediately. This can be reasonable in the short term if the environment is stable, no upgrades are planned, and existing packages meet current requirements.
You can wait for the community RPM effort to mature (requiring the least immediate change, but offering no predictable future) or build and maintain RPM packages internally (offering control, but creating a heavy, ongoing burden of tracking dependencies, security updates, and build infrastructure).
Either option postpones the problem. Whenever your organization needs security fixes, new hardware, an OpenStack upgrade, or experiences a team change, the cost and risk of an unsupported or self-maintained path become highly visible. The goal is not to create unnecessary urgency, but to ensure you have a considered plan before an incident forces a decision under pressure.
Before Transitioning Your Environment
We understand that an RDO-based OpenStack cloud is not a generic installation that can be updated simply by swapping a repository.
The appropriate transition depends heavily on your existing environment. Important questions include:
- Which OpenStack release is currently in use?
- Which operating system and version are deployed?
- How is the cloud automated and configured?
- Which networking and storage integrations are in place?
- Are there custom drivers, third-party components, or workload-specific requirements?
The exact route should be confirmed during a technical assessment. Depending on your setup, it may involve an in-place upgrade, a staged transition, or a parallel deployment with controlled workload migration.
Discuss Your Path Beyond RDO
If your OpenStack environment relies on RDO RPMs, the immediate question is not whether you must redesign everything at once. It is which route will give you a sustainable, supportable future.
Sardina Systems can assess your current OpenStack release, operating system, automation, and operational requirements to help you design a smooth, supported path forward with FishOS. Click here to schedule a complimentary introduction call with us.