How to plan an OpenStack upgrade with Kolla-Ansible
Plan an OpenStack upgrade around the SLURP path, and run it as a Kolla-Ansible runbook with backups, prechecks and rollback points at every stage. If your containerized cloud runs an older release in data centers or private networks you control, the first planning task is to record the exact release in service, along with the Kolla-Ansible version and the container image tags that deployed it. Those records define your starting point. The destination is then chosen from the SLURP releases the community supports for upgrades from that starting point, and that decision should be made by your team, with a partner if you use one, before any host is touched.
OpenStack ships on a six-month cycle, and since the 2022 cadence change the community supports upgrades between SLURP releases as well as between adjacent releases. The SLURP releases named for this path are 2025.1 Epoxy, released on 2025-04-02, and 2026.1 Gazpacho, released on 2026-04-01. Between them sits 2025.2 Flamingo, released on 2025-10-01. It is a maintained release and a valid stopping point, and a direct move from Epoxy to Gazpacho can skip it. Whether that skip is supported for each service and version in your environment is something the release notes must confirm, so treat the cadence as a starting assumption and the release notes as the authority.
The second driver is the stable branch support window. Stable branches are maintained for approximately 18 months. After that, only SLURP releases may move into an unmaintained phase, where releases stop and CI is reduced, before end of life. A cloud on a release that has left its maintained window receives no further fixes, and the deadline is set by the branch's phase. Map your current release to its phase, note the date it leaves the maintained window, and count backward from that date to the change windows your organization can actually schedule. Record that deadline in the runbook so the upgrade is planned ahead of a support expiry.
Before scheduling work, confirm the path in three places: the release notes for each intermediate and target release, the upgrade documentation for the release you are moving to, and your own deployed version and configuration. The usable path depends on the release running today, and skip support may differ by service. Write the plan as a runbook with one stage per release hop. Attach to each stage a configuration backup, a precheck run, the image pulls and a named rollback point, and place a decision gate after each stage so that a failed check stops the sequence before the next hop begins.
Several decisions should be settled before the first stage starts. Name who approves each gate and who can halt the sequence. Set the maintenance windows, and decide how long each rollback point is kept and how restores will be tested. Choose which services are in the first run, since a cloud with many services and a complex network layout will need more verification than a small one. A partner quote should follow from this written scope and should show the number of hops, the services deployed, the size of the environment, and the backup and test work each stage requires.
What changes across the releases and what each change means for the upgrade
This table sets out the cadence rules, release dates and branch support windows that shape an OpenStack upgrade with Kolla-Ansible, and what each one means for your plan. Read it in order: identify your current release, check whether it is a SLURP release, then confirm its maintenance status and the window that applies. Service-level changes are not covered here, so read the per-service release notes for each component you run.
| Change | Impact | Action needed |
|---|---|---|
| Release cadence since 2022 | Upgrades are supported between adjacent releases and between SLURP releases, so SLURP releases act as planning anchors for a multi-release move. | Map your current release and target onto the SLURP sequence, then confirm the supported path in the Kolla-Ansible release notes for each step. |
| 2025.1 Epoxy (SLURP, released 2025-04-02) | Remains in the maintained phase and is a SLURP starting point for a skip-level move toward 2026.1 Gazpacho. | If you run Epoxy, confirm it is still receiving releases and plan the direct path to the next SLURP release. |
| 2025.2 Flamingo (released 2025-10-01) | Remains in the maintained phase but is not a SLURP release, so it sits between SLURP anchors in the upgrade sequence. | If you run Flamingo, decide whether to step to Gazpacho directly or through an intermediate release, and check the release notes for that step. |
| 2026.1 Gazpacho (SLURP, released 2026-04-01) | A SLURP release with a Kolla-Ansible deployment guide in the 2026.1 documentation, making it a common target for SLURP-aligned plans. | Read the 2026.1 deployment guide, then run prechecks and a full upgrade rehearsal on a staging copy of your configuration. |
| 2026.2 Hibiscus (released 2026-09-30) | The newest release in the supplied timeline and not a SLURP release. The next SLURP release, 2027.1 Indri, has an estimated release of 2027-03-24. | Decide whether to target Hibiscus or wait for the SLURP release, and confirm the estimated date on the OpenStack releases site before you set a plan. |
| Stable branch maintenance window (about 18 months) | Stable branches receive fixes for approximately 18 months, so a cluster on an older branch can lose backported fixes before it upgrades. | Record the release date of your branch, calculate when its window closes, and schedule the upgrade with that date as a hard constraint. |
| Unmaintained phase for SLURP releases | After the window, only SLURP branches may enter an unmaintained phase with no releases and reduced CI, before end of life. | If your branch is past its window, confirm its status on the releases site and plan the move before it reaches end of life. |
Why the supported OpenStack upgrade path runs between SLURP releases
The 2022 cadence change determines which upgrade paths a Kolla-Ansible cloud can follow today. OpenStack historically released on a six-month cycle and supported upgrades only between adjacent releases. The 2022 resolution from the OpenStack Technical Committee made upgrades supported between SLURP releases as well, so a team on an older release should first identify its current version and then map it to the SLURP release the project documents as a target. That mapping sets the route the team can legitimately take, so it belongs in the plan before any change window is booked.
Staying on the adjacent path means upgrading each release in order. A cloud on 2025.1 Epoxy would move to 2025.2 Flamingo and then to 2026.1 Gazpacho, which is two upgrade cycles. Each cycle repeats the Kolla-Ansible sequence: configuration backup and merge, prechecks, image pulls, the service upgrade and validation. The advantage is that each step is smaller, and the team sees how each release behaves on its own cloud before moving on. The cost is repeated change windows, repeated staging rehearsals and a rollback point for every step. In regulated environments, each cycle also means another round of change approval and evidence collection.
Skipping intermediate releases reduces the work to one cycle, such as a direct move from 2025.1 Epoxy to 2026.1 Gazpacho. Fewer cycles mean fewer change windows and fewer rehearsals, but the single step is larger and carries more risk in one pass. A skip is supported only on the path the project documents. A jump that works in a lab but is not on the documented path is still unsupported, and its failures may surface later in the database or the message queue. Before scheduling, confirm the exact source and target pair in the OpenStack release documentation and the Kolla-Ansible upgrade notes, and check that every service you run is covered on that path. The detailed constraints for the Epoxy to Gazpacho skip are covered in the dedicated sibling guide.
The age of the current release also shapes the decision. OpenStack stable branches are maintained for approximately 18 months, and after that only SLURP releases may enter an unmaintained phase with no releases and reduced CI before end of life. A team several releases behind may find its starting point is no longer receiving fixes, which can make a shorter path more urgent than a cautious step-by-step plan. Ask your internal team or implementation partner to write down the source version, the target SLURP release, the number of upgrade cycles and the rollback point for each step. Confirm each entry against the release notes for that version before the plan is approved.
What to back up and inventory before the first precheck
Six preparation tasks have to finish before the first precheck, and each one feeds the next. Together they let the team document the current cloud, restore it if needed and compare the upgrade against a known baseline. Confirm owners and sign-off steps in your own change process before work starts.
Configuration backup and merge plan
Copy the full Kolla-Ansible configuration, including globals.yml, passwords.yml, the inventory file and any files under the config override directory, into version control or an offline store before anything changes. Then write a merge plan that records, for each option, whether the new release default is adopted or the local value is kept. Owner: the platform lead who signs off the plan. It protects against silent loss of tuned settings and against a precheck that passes while a required option has drifted.
Database and message queue backups
Take a consistent backup of the MariaDB databases used by the cloud, and export RabbitMQ definitions, users and queue configuration. Restore both to a separate host to confirm the procedure works before you rely on it. Record how long backup and restore take in your environment, because the duration depends on your data volume and hardware. Owner: the database administrator, with the messaging owner. It protects against failed schema migrations and lost queue or user definitions during an upgrade step.
Inventory of customizations
List every local change: custom configuration overrides, plugins, drivers, custom container images and any patched service code. Mark which items the target release supports natively, which need a rebuild and which must be retired or replaced. Owner: the cloud architect, with the service owner who requested each change. It protects against an upgrade that quietly removes a driver or plugin the business depends on, a gap that often surfaces only when compute or storage operations fail.
Test environment from production copy
Build a non-production environment from a copy of the production configuration, keeping the same Kolla-Ansible version, host groups and network layout where practical. Run the full upgrade sequence there first and keep its results as the reference for production. Owner: platform engineering, with the security team confirming that copied data and credentials are handled under your data policy. It protects against discovering configuration errors for the first time in production.
Image registry and pull capacity
Confirm that every container image for the target release is available in your internal registry or mirror, and that every host can pull them without exhausting bandwidth or hitting registry limits. Verify image tags or digests against the release you planned. Owner: platform engineering, with the network team for bandwidth and firewall rules. It protects against a rolling upgrade stalling partway because some hosts pull successfully and others fail, leaving mixed container versions in the cloud.
Documented rollback plan
Write the rollback plan before the first precheck. It should state which backups restore which components, who has authority to call a rollback, which runbook steps are the last points where rollback is still practical, and how tenants will be informed. Include the checks that confirm a restored cloud is healthy. Owner: the change owner, approved by the service owner. It protects against improvised recovery under pressure and sets the point at which the team stops and restores.
Why the RabbitMQ one-major-version rule and partial --limit runs need planning
The upgrade plan must check the RabbitMQ broker version before any OpenStack service is run. RabbitMQ can move only one major version at a time, so a broker that is further behind the target release may need an intermediate step before the Kolla-Ansible run can proceed. Treat this check as a gate. Record the broker version on every node that runs it, compare it with the version the target OpenStack release requires, and confirm the required sequence in the Kolla-Ansible and RabbitMQ documentation for your release. If the broker is not where the plan expects, stop and revise the plan before any container image is pulled or any service restarts.
Partial runs with the Ansible --limit option are avoided because they can leave services on different releases. An operator may be tempted to upgrade one host group, such as compute nodes or a single controller, to shorten a maintenance window. The services in that group can then run a newer release while the services they depend on still run an older one. An upgraded API may receive calls from a service that has not moved, and message formats on the broker may differ between the two sides. These incompatibilities often surface only under load or in specific code paths, which makes them slow to diagnose.
Decide the run scope in the written plan before the window opens. List every host group and service the run touches, and mark the ones that must move together. Confirm from the Kolla-Ansible documentation for your release whether any subset is supported on its own. If the documentation does not support a subset, the run is full scope and the window must be sized for it. Record the decision, the reason for it and the name of the approver. Also document what the team will do if the run stops midway, so that nobody improvises a limited run during an incident.
A partial state can be recognized by a few observable signs. Running containers on different hosts may carry different image tags, services may report different versions, and logs may show API or broker errors soon after a service restarts. Configuration rendered for the target release may also be present on hosts that are still running the source release. Compare image tags and running versions for each host against the plan after every stage. If the state is partial, do not start a second limited run to fill the gap. Treat it as an incident and follow the rollback and recovery steps written before the window, using the commands and checks confirmed for your release.
The upgrade sequence from precheck to verified cutover
This sequence moves a Kolla-Ansible cloud from change freeze to a closed change record, with a check and a named rollback point at each stage. Steps up to the full-deployment run can be reversed, but the upgrade run applies database changes that only a database restore can undo.
Freeze change and confirm the target release
Stop unrelated changes to the cloud for the upgrade window and record the current and target releases in the change ticket. Confirm the target against the OpenStack releases site and use the Kolla-Ansible branch that matches that release, since 2026.1 Gazpacho is a SLURP release and 2026.2 Hibiscus is a later release. The change owner and approver sign off the release pair and the rollback approach before any backup is taken. Done when the ticket names both releases, the approver and the window. Rollback point: none yet, because no system has changed.
Back up configuration and databases
Copy the Kolla-Ansible configuration, including globals.yml, passwords.yml and every merged override, and dump each OpenStack service database. Compare the target release's sample configuration with your merged copy so your overrides carry forward deliberately. Store the copies off the control node and restore one database dump into a scratch instance to prove it works. Done when the copies are listed with checksums and the restore test has passed. Rollback point: the restored configuration and the database restore point, both used if the cutover fails.
Verify the RabbitMQ version against the rule
Check the RabbitMQ version running in the cluster and the version the target release expects. The rule allows one major RabbitMQ version per upgrade, so a larger gap must be closed through intermediate steps that each follow the rule. Confirm the path against the target release notes and record it in the change ticket. Done when the current version, the target version and each intermediate step are written down and reviewed. Rollback point: none needed at this stage, because the cluster is still on its original version.
Run prechecks and resolve every failure
Run the Kolla-Ansible prechecks against the full inventory, which checks host and service state without changing anything. Fix each failure at its source, then rerun the prechecks until the output reports no failures. Do not proceed on a warning you have not explained in the change record. Done when a clean precheck run is saved with the change ticket. Rollback point: none required, since prechecks only read state.
Pull images to all hosts first
Pull the target container images onto every host in the inventory before any service is restarted or changed. Confirm the pulled tags match the target release, and leave the currently running images in place so they remain available on each host. Done when every host reports every required image and the image list matches the change record. Rollback point: the previous image tags stay on each host, so the image rollback is available if a later step fails.
Run the upgrade across the full deployment
Run the Kolla-Ansible upgrade against the complete inventory, avoiding a subset selected with --limit, because a partial run can leave services on mixed releases. This step applies database migrations, and redeploying older images does not reverse them. Watch each play for failures and stop on the first error you cannot explain. Done when the play recap shows no failed hosts. Rollback point: the database restore point combined with the image rollback. This step is one-way for the database schema.
Run post-upgrade checks per service
Verify identity, compute, networking, storage and the message queue, starting with identity because other services depend on it. For identity, confirm token issuance and the service catalog. For compute, list hypervisors and confirm instance state. For networking, check agents and routers. For storage, confirm volume services and Ceph health if you use it. For RabbitMQ, confirm every cluster node is running and queues are not backing up. Done when each area has a recorded check. Rollback point: restore the databases and images if a service cannot be repaired forward.
Run functional tests and close the change
Run functional tests that create, boot, attach, route and delete test resources in a test project, covering the workloads you run in production. Record the results, open defects and any workarounds in the change ticket. Keep the pre-upgrade backups for the retention period your policy sets, then have the approver close the change. Done when the tests pass or each failure has an accepted disposition and the change is closed. Rollback point: the backups and restore points remain available until the change closes.
How to test an OpenStack upgrade and decide on rollback
Build the test environment from production configuration, and run the same release path you plan to use in production, including any SLURP step. Copy the Kolla-Ansible globals file, the inventory, the service overrides, the Ceph backend settings and the Keystone federation mapping rules into the test environment. Keep the network layout, certificates and container image sources identical as well. Record the configuration state before and after each rehearsal so that any difference in behavior can be traced to a specific setting. Ask your platform team to confirm which customizations, such as locally built container images or patched service code, must be rebuilt for the target release. Those items are a common reason a rehearsal passes while the production run fails.
Define the test cases and their pass criteria before the first rehearsal begins. Identity testing should cover password logins and federated logins through your identity provider, and it should confirm that mapping rules still place each user into the expected groups, roles and projects. Instance lifecycle testing should create, stop, start, resize, snapshot and delete instances. Volume testing should attach and detach Cinder volumes to running instances and confirm data integrity afterward. Network testing should check internal traffic between instances, external connectivity and floating IP assignment. Image testing should upload a Glance image, boot an instance from it and confirm it reaches the expected state. Finally, restore a database backup and a volume backup into a scratch environment to prove that the backups you rely on for rollback can actually be used.
The rollback decision depends on whether the failed step has changed the database schema. Before any database migration runs, a failure is usually recoverable by redeploying the previous container images and restoring the configuration saved at the start of the change. After a migration completes, returning to the old code does not return the schema, and the old services may refuse to start against the new tables. In that case the only in-place path is a restore of the database to a point before the change. Anything written to the database after that point, including instances, volume records and project changes, will be lost unless you reconcile it by hand. Check the release notes for each affected service to identify which migrations are irreversible, and confirm those findings with your vendor or upstream documentation before the change window.
Rehearse the rollback itself, not only the upgrade. Time the restore of the database, the redeployment of the previous images and the checks that confirm service health, and record which steps need an operator with specific access. Write a go or no-go deadline into the change plan, expressed as a checkpoint that the team fixes in advance, such as the point after prechecks, after each service group or after the first migration. At each checkpoint, name the person with authority to decide, the criteria that trigger a rollback and the data that would be lost if the team reverts. A decision made against a written deadline is far easier to defend than one made under pressure after the window has already closed.
Effort drivers for an OpenStack upgrade with Kolla-Ansible
This table lists the inventory factors that most change the effort of a Kolla-Ansible upgrade, with the reason each one adds work and the item to measure before scoping. Read each row against your own cloud, because heavy customization, many plugins or several identity sources can change the plan more than host count alone. The main takeaway is that effort grows with customization and service count, so measure these items before asking for a quote.
| Driver | Why it adds effort | What to confirm |
|---|---|---|
| Custom configuration and overrides | Overrides in globals.yml and per-service files must be merged with new release defaults, and each conflict needs a decision. | Count override files and every key set outside the defaults in your configuration directory. |
| Custom or third-party drivers and plugins | Storage, network or compute drivers may lack builds for the target release and need separate testing. | List each driver and plugin with its version and whether its vendor supports the target release. |
| Number of enabled services | Each enabled service brings its own container image, database schema changes and post-upgrade checks. | Count the enable_* flags set to yes in globals.yml and identify services no one uses. |
| Database size and migration complexity | Large schemas and long migration histories extend the downtime window and raise the chance of slow or failed steps. | Measure each service database size and review pending migrations since your current release. |
| Message queue topology | The RabbitMQ cluster layout and the one-major-version rule determine how many restart stages the upgrade needs. | Document node count, queue types, high availability settings and the current RabbitMQ version. |
| Number of hosts and availability zones | More hosts and zones add rolling steps, image pulls and points where one stalled node blocks progress. | Inventory control, network, compute and storage hosts, plus availability zones and their host groups. |
| Identity federation and mapping rules | Federated logins depend on mapping rules and trusted identity providers that must be retested after the upgrade. | List each identity provider, its protocol (SAML 2.0 or OpenID Connect) and its mapping rule set. |
| Ceph storage integration | Glance, Cinder, Nova and backup pools on Ceph need compatible client libraries and healthy cluster checks. | Record the Ceph release, the pools and clients OpenStack uses, and cluster health before the window. |
| Test environments and change window | Each environment needs its own rehearsal, and a fixed change window limits how many rehearsal and rollback cycles fit. | Count non-production environments that mirror production and the approved hours for each change. |
What buyers ask before hiring help for an OpenStack upgrade
What drives the cost of an OpenStack upgrade with Kolla-Ansible?
The main drivers are the number of OpenStack services enabled in your cloud, how far your current release is from the target, how much custom configuration and integration exists, and how many environments (test, staging, production) must be upgraded and verified. Each one adds planning, rehearsal and validation work. Cost is partly one-time (assessment, upgrade rehearsal, the cutover and the handover) and partly recurring if you keep a partner on retainer for later releases. Ask for a fixed-scope proposal that lists the environments, services, integrations and deliverables in writing. DeployOpen does not publish a price list, so the quote follows from that written scope.
What should a written quote for an OpenStack upgrade include?
A useful quote states the scope in specific terms: the current and target releases, the Kolla-Ansible version and deployment inventory, the services covered, the integrations to be checked (such as identity federation and Ceph-backed storage), and the environments included. It should list deliverables such as the configuration backup and merge record, prechecks, the rehearsal report, the runbook, the rollback plan and the handover documentation. It should also name the client responsibilities, the assumptions about access and change windows, what is excluded, and the process for changes to scope. Ask how post go-live testing and support are billed and whether they are separate from the upgrade itself.
How long does a Kolla-Ansible OpenStack upgrade take?
Duration depends on scope rather than a fixed figure. The size of the cloud, the number of services in use, the gap between releases, the state of your configuration, and the number of rehearsals needed all change the schedule. Clouds with heavy customization or many integrations need longer validation. The release calendar also affects planning: OpenStack 2026.1 Gazpacho is a SLURP release, and 2027.1 Indri is still in development, so target choice should be made with the maintained phase in mind. Ask the partner to show how they estimated the schedule, which assumptions it depends on, and which steps would extend it.
What does the client need to provide for an OpenStack upgrade?
The client provides access to the control plane, compute, storage and deployment hosts, plus the Kolla-Ansible configuration and inventory. You need named owners for identity (usually Keystone and any federated directory) and for storage (typically Ceph, Cinder and Glance), because their decisions affect the upgrade order and rollback. Change windows must be booked in advance, and someone with authority must sign off the rollback plan before production work starts. Expect to supply test capacity for rehearsals, and a point of contact who can approve a stop if validation fails. Confirm these responsibilities in the written scope so that delays are traceable.
Can an internal team upgrade OpenStack with Kolla-Ansible without a partner?
Yes, an internal team can perform the upgrade if it has operators who understand Kolla-Ansible, Ansible, container runtimes, OpenStack service dependencies and the storage and identity systems in use. The harder parts are usually rehearsal discipline, rollback preparation and the verification of integrations after cutover. A partner is most useful when the team has not yet run an upgrade of this kind, when the cloud is heavily customized, or when staff capacity is limited during the change window. Many organizations split the work: internal staff own the production steps and the partner supplies planning, runbook design, rehearsal support or independent review. Assess your team's skills against the runbook before deciding.
Why do upgrade plans avoid upgrading only part of a cloud?
Upgrading only some hosts or services with a limit flag can leave the cloud in a mixed state, where services expect different versions of the same interfaces or message queue. The RabbitMQ one-major-version rule is one example: nodes and dependencies must move in a sequence that stays inside the supported version steps, so an incomplete run can break messaging across the control plane. Partial runs also make rollback harder to reason about and make the test results less representative of production. The usual approach is to upgrade the whole environment in a planned order, rehearsed in a non-production copy first. Confirm the exact constraints for your release pair in the official upgrade notes.
Can I skip a release during an OpenStack upgrade?
Skip-level upgrades are supported between SLURP releases, which is part of the OpenStack release cadence adopted in 2022. A move from 2025.1 Epoxy to 2026.1 Gazpacho is a SLURP-to-SLURP path, but support is not automatic for every service or every database and message queue step. Each project must be checked for the specific skip, and migrations, configuration changes and deprecations must be reviewed for the versions in between. Confirm the supported path for your release pair with the OpenStack release documentation and your Kolla-Ansible version before planning. A rehearsal in a copy of your environment is the practical way to confirm the skip works for your services.
What support is available after an OpenStack upgrade goes live?
Support after go-live is usually split into a stabilization period covered by the upgrade scope and an ongoing arrangement chosen separately. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so a team can keep a partner for incident help, the next release, and periodic verification. Follow-up testing should check the integrations, backups, monitoring and access controls that changed during the upgrade. Stable branches are maintained for approximately 18 months, so plan the next upgrade before a release leaves the maintained phase. Ask what response expectations, handover documents and retest cycles are included in the written scope.
How DeployOpen scopes and delivers the upgrade
DeployOpen plans and runs Kolla-Ansible upgrades inside infrastructure you control, under a written scope agreed before work starts. Each run follows one documented runbook covering configuration backup and merge, prechecks, image pulls and controlled rollout across the whole cloud. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Current and target OpenStack releases, confirmed against the SLURP cadence before any runbook is written.
- Inventory of your globals.yml, service overrides, custom images and inventory file.
- Written scope listing cluster nodes, services in use, maintenance windows, rollback criteria and deliverables.
How we build
- Configuration backup and merge of globals and passwords files against the new release defaults.
- Prechecks run on every node, with failures resolved before any container is replaced.
- Container images pulled ahead of the change, and RabbitMQ stepped one major version at a time.
How we hand over
- Full-cloud upgrade runs without --limit partial passes, so every node lands on the same release.
- Runbook documenting each step, its checks, rollback points and the operator who signed it off.
- Operator walkthrough of prechecks, image pulls and the upgrade run with your team.
How we support
- Retainer option for upgrade support, patch releases and continuous testing after handover.
- Post-upgrade verification of services, databases and message queues before the change is closed.
- Support scope and response terms written into the contract, confirmed with us before signing.
