OpenStack 2025.1 Epoxy to 2026.1 Gazpacho SLURP upgrade

The SLURP path is only a safe shortcut if you read the release cadence correctly. OpenStack has historically released on a six-month cycle, so a cloud that upgraded at every release would move through each one in turn. The 2022 cadence change altered that by allowing upgrades between SLURP releases in addition to upgrades between adjacent releases. In this case, 2025.1 Epoxy (released 2025-04-02) and 2026.1 Gazpacho (released 2026-04-01) are both SLURP releases, so the cadence change is what makes a direct move between them a documented option. 2025.2 Flamingo (released 2025-10-01) is the release in between. The cadence permits the skip, but permission at the release level does not settle what happens inside each service.

The skip is a per-project question, and this is where most of the planning effort belongs. Each OpenStack service is maintained by its own project team, and each team decides which upgrade paths its code and database migrations support. A cloud running Keystone, Nova, Neutron, Glance, Cinder and Placement, among others, needs an answer for every service it runs. Read the Flamingo and Gazpacho release notes and upgrade sections for each one, and confirm with the project teams wherever the notes are silent. Build a service-by-service table that marks each component as supporting the skip, requiring an intermediate step through Flamingo, or unknown. Treat any unknown entry as a blocker until it is resolved.

Stable branch maintenance decides when the team must move. OpenStack stable branches are maintained for approximately 18 months. After that, only SLURP releases may enter an unmaintained phase, which means no further releases and reduced CI, before end of life. Epoxy is a SLURP release, so its stable branch can enter that phase after its maintained period, but the current status should be checked on the OpenStack releases site before the deadline is set. Flamingo is not a SLURP release, so the team should confirm its end of maintenance on the same site. Because maintained branches receive the fixes you depend on, a team that waits for the last safe moment has less room to recover if a skip-level test fails.

Before committing, run the skip in a non-production environment built from the same deployment configuration, and record the result for each service. Keep Flamingo as the documented fallback path. If a service needs the intermediate step, the team should know which migrations, configuration changes and service restarts that step adds before the production window opens. Ask the team that will run the upgrade to confirm the deployment tool version, its prechecks and its rollback steps for the skip path, because tool guidance may follow the release order. Record each service as a documented go or no-go, signed off by the people who operate that service.

Each OpenStack service owns its database schema and runs its own migrations during an upgrade, so the schema step is a per-service task rather than one event for the whole cloud. Before you schedule the Epoxy to Gazpacho move, build a list of every service you deploy, including identity, compute, networking, image, block storage, placement and any orchestration or key management services in your design. For each one, confirm which schema migrations cross from the 2025.1 release to the 2026.1 release, and the order in which they must run. Do not assume that a skip-level path changes nothing because intermediate releases are skipped. The release notes and upgrade notes for each service on the target release are the starting sources, and your own deployment's database state is the final check.

Turn that research into a written migration plan that your team and any partner can review. For each service, record the schema change, whether it can run while the service is still serving requests, what downtime it implies, who runs the command, and what evidence proves it finished. Take a verified database backup before the first container changes, and restore that backup to a separate environment to confirm it works. The migration order also affects rollback, because after a schema has moved forward, restoring the old container images alone may not bring the old schema back. Your rollback plan therefore needs a tested database restore path for every service whose schema changes.

The message queue deserves the same attention as the databases. In most Kolla-Ansible deployments, RabbitMQ is the broker that carries remote procedure calls and notifications between OpenStack services, so a broker problem stops services even when their databases are healthy. Before moving any service, record the RabbitMQ version your cluster runs today and check it against what the target release and your deployment tooling expect. The sibling Kolla-Ansible upgrade runbook covers the RabbitMQ one-major-version rule and the sequence for moving the broker. Follow that runbook for the broker steps, and confirm the rule against the RabbitMQ version in your own environment before you start.

A partial run, where the upgrade is limited to some hosts or services with the --limit option, is one of the easiest ways to create an unrecoverable mix of versions. Services that exchange messages through the broker can end up on different releases, with schemas and message formats that the other side does not expect, and the failures may appear hours later under normal load. If a maintenance window cannot hold the whole run, agree the split in writing before starting. Define which hosts move together, which verification must pass between batches, and who can stop the run. Keep an inventory of image tags on every host at each stage so the state of the cloud is known at any point.

Plan the rollback before the first change window, because a rollback is only clean up to the point where an irreversible database schema change has been applied. Once a service's migrations have run in a way that the previous release cannot read, the realistic recovery path is a restore from backup, not a downgrade. Your plan therefore has to name, for each service in the 2025.1 Epoxy to 2026.1 Gazpacho path, the moment after which you stop treating the change as reversible. Confirm that point with the release notes and upgrade documentation for each project rather than assuming it from the release name.

For each service, confirm in writing whether downgrade is supported between the two releases. Do not assume that a service supporting a downgrade from its adjacent release also supports one across a skip-level jump, because the direct path from Epoxy to Gazpacho is the case you are testing. Where downgrade is not supported, define the restore path before the upgrade: which backup set is restored, who authorizes the restore, how control plane and database state are brought back into agreement, and how you confirm that instances, volumes and network state still match what the control plane reports. Record the decision points so the on-call team does not have to reason about them under pressure.

Your test scope should exercise the paths that users and automation depend on, not only whether containers start. Cover API smoke tests against each core service endpoint, and a full instance lifecycle: create, boot, snapshot, stop, resize or migrate where your design allows it, and delete. Test Keystone login for local users and for federated users coming through your identity provider, including the mapping rules that place them into groups, roles and projects. A federated login that succeeds while the mapping no longer resolves to the right project is a failure, so check the resulting role assignments explicitly.

Extend the test scope to storage and networking. Upload Glance images and confirm they can be booted. Attach and detach Cinder volumes to running instances, and verify data is intact after detach. If you use Ceph block devices for Glance, Cinder and Nova guest disks, test a boot from Ceph and a live volume attach, because a storage backend fault can look like a control plane fault. Finally, verify network paths between tenant networks, the external network, and the metadata and DHCP services, since a successful API response does not prove that traffic flows. Use a fixed test set, record results before and after each stage, and compare them against the same baseline on every rerun.

Treat the test results as the input to your go or no-go decision, and agree the criteria in advance. Decide who can declare a failure, which failures stop the change window, and which can be carried forward with a known issue. Confirm the backup you will restore from has been tested by restoring it into an isolated environment, not only that the backup job reported success. Document the sequence of steps, the owners and the communication path. Confirm any duration estimates for your own environment with your team and the vendor documentation, since the time a restore or rollback takes depends on data volume, network bandwidth and the number of services affected.

Keystone federation has to be tested with real federated logins once the control plane runs the 2026.1 Gazpacho code. A configuration that loads without errors does not prove that users still arrive in the right place. Test at least one account from each identity provider over each protocol the cloud accepts, whether SAML 2.0 or OpenID Connect. Confirm that the login completes and that the resulting token is scoped to the project the user expects. Check every mapping rule in turn. Mapping rules decide which groups, roles and projects a federated user receives from the attributes the identity provider sends, so a rule that matched before the upgrade can quietly miss a user now. Include an account that should be denied and confirm that the denial happens. If you federate one Keystone to another, run the same tests from both sides.

Keep a dated copy of the identity provider metadata, the federation settings and the mapping rules from the 2025.1 Epoxy environment before the change window. After the upgrade, compare the live results for each test account against the recorded baseline. Ask the platform team to confirm in the 2026.1 release notes whether any federation option, default or rule syntax changed between the two releases. If a signing certificate or metadata key expires near the window, schedule its renewal separately so that a federation failure is easy to tell apart from an upgrade defect. Assign one person to run the test script and a second person to check the results. Record each login, the attributes received, and the group, role and project assignments that followed.

Ceph integration needs its own check because Glance, Cinder and Nova all depend on the same storage cluster, and each authenticates with its own Ceph client identity and pool access. After the upgrade, confirm that each service still reads its keyring and configuration. Then run the operations that exercise each path. Upload an image into Glance and boot an instance from it. Create a Cinder volume, attach it to a running instance, and take a Cinder backup. Boot an instance with its root disk on Ceph so that Nova's guest disk path is tested, and do not stop at scheduling. Check that every compute host can reach the Ceph monitors and OSDs, because a host missed during redeployment will fail only when a workload lands on it.

Before the change window, confirm that the Ceph client packages or containers on the controllers and compute hosts are supported by the 2026.1 Gazpacho release and by the Ceph release your storage cluster runs. Use the compatibility information that the Ceph and OpenStack projects publish for the target release, and record the exact client and driver versions you tested. If the Ceph cluster itself needs an upgrade to stay in a supported combination, schedule that work as a separate, earlier change with its own rollback point, since it changes the storage layer under the OpenStack upgrade. Ask your implementation partner to state in writing which Ceph client version each OpenStack service will use after the upgrade. Keep the previous client images available so the Ceph client can be rolled back without reverting the whole cloud.