OpenStack upgrades and support

The first planning decision for an OpenStack upgrade is which release you are moving to, and that choice depends on how OpenStack releases are scheduled. OpenStack has historically shipped on a six-month cycle. Since the 2022 cadence change, the community supports upgrades between SLURP releases as well as between adjacent releases, so a cloud does not have to step through every release in between. SLURP releases are the ones the project designates for longer-term upgrade paths, and they are the releases to plan around when you want fewer upgrade hops.

The maintained window is the second constraint. OpenStack stable branches are maintained for approximately 18 months. After that, only SLURP releases continue into an unmaintained phase, where the project publishes no further releases and runs reduced CI, before end of life. A release that has left the maintained window is not a safe place to park production, because security and bug fixes will stop arriving through the normal stable process. Your upgrade plan should therefore check, for each candidate target, whether it is still maintained when you expect to finish the work and when you expect to need the next upgrade.

The releases named in current planning material are 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho (a SLURP release), 2026.2 Hibiscus, and 2027.1 Indri, which is in development with an estimated release date of 2027-03-24. Status changes as the calendar moves, so confirm each release's current phase on the OpenStack releases site on the day you start planning. Do not rely on a status copied from an older document, a vendor deck or this page. Record the phase, the release date and the estimated end of maintenance in your upgrade design document, with the date you checked them.

In practice, choose a target SLURP release where the upgrade path allows it, and check that the path from your current release to that target is supported by the release notes and upgrade documentation for each service you run. Each release you skip is additional testing: it adds configuration changes, database migrations and API behavior changes that your test environment must exercise. Ask your partner or internal team to estimate how many intermediate releases each option would require and what testing each step needs, and ask for those estimates in writing so you can compare options on evidence rather than on release names alone.

The upgrade itself is a finite project, but running an OpenStack cloud afterwards creates recurring cost lines that should be budgeted before the first upgrade is signed off. The largest of these is ongoing support, usually billed as a retainer with a set number of hours or as a monthly service level agreed in writing. Support covers triage of tickets against the control plane, Nova, Neutron, Cinder, Glance and Keystone, and the response to failed live migrations or stuck instances. Ask whether the retainer includes on-call coverage outside business hours, and what counts as an incident versus a change request.

The second recurring line is the upgrade cycle itself. Each time you move to a new release, the work repeats: release notes review, configuration changes for the Kolla-Ansible or OpenStack-Ansible deployment, staging rehearsal, service-by-service testing and a production run. Whether you move from one SLURP release to the next, or step through adjacent releases, changes the number of cycles across a given period. The stable branch of each release is maintained for approximately 18 months, so an upgrade plan built around the maintained window needs a dated decision on which release to target next. Ask the partner to state the release path in the quote, including the releases skipped and the testing each step requires.

Patching within maintained branches is a smaller but steady line. Minor updates to the chosen release, along with container image rebuilds, dependency updates and host operating system patches, need test runs in staging before production. Monitoring and backup verification also recur. Someone must review alert thresholds, confirm that Ceph or other storage backups restore successfully on a schedule, and record the results. These tasks are easy to underestimate because they produce no visible change when they succeed, so put them in the scope as named activities with a frequency rather than as general support.

Staging and test environments carry a cost that many budgets omit. A usable rehearsal environment needs compute, storage and network capacity close enough to production to surface real problems, along with the power, cooling and rack space to host it. Your data center team should confirm these costs in its own accounts, since they depend on your facilities. Internal engineers also carry recurring cost: they review changes, approve maintenance windows, respond to incidents and maintain the knowledge needed to operate the cloud between partner engagements.

DeployOpen does not publish a price list. Retainers and fixed-scope upgrades are quoted from the written scope, and the one-time work (initial assessment and rehearsal) is priced separately from recurring support. When you request a quote, ask for the release path, the response expectations agreed in writing (including severity levels and hours covered), the testing scope for each service and the handover package, meaning the runbooks, configuration under version control, test results and rollback steps your team keeps after the engagement ends.

The first requirement is access to the source of truth for your cloud. Your team needs read and change access to the deployment repository, whether it holds Kolla-Ansible or OpenStack-Ansible code, along with the inventories, global settings and per-host overrides that produce the running control plane and compute nodes. Everything should sit under version control. Before the engagement starts, ask whether the repository matches what is deployed on each controller, network node and hypervisor. Any drift found at this stage, such as a hand-edited configuration file on one host, must be recorded and resolved, because an upgrade run from the repository will not reproduce a change that only exists on a server.

Next, provide a current backup and a restore test record. A backup file alone does not show that the cloud can be rebuilt. The record should cover the Keystone, Nova, Glance, Cinder and Neutron databases, the Glance images, the Cinder volumes and backups, and the Ceph pools that hold them if Ceph is part of the design. For each item, the record should show the date of the last successful restore test, who ran it, the scope tested and the time taken. If no restore test has ever been run, make that the first task, carried out in staging before any upgrade planning continues.

Your team must also provide a staging environment that resembles production. It should run the same OpenStack release, the same hypervisor and Ceph versions where possible, a comparable network segmentation design and enough spare compute to evacuate representative workloads during testing. Confirm the staging capacity in writing, since a smaller staging cloud will pass tests that production would fail. In addition, name one accountable owner each for compute, storage, network and identity. These owners must be able to approve changes in their area and to answer questions during the work without waiting for a committee.

Finally, your organization must make three decisions and record them. First, agree the target release. Upgrades are planned between releases, and the choice of target determines the test scope and the length of the maintained window that follows. Second, define the acceptable downtime for tenants, including whether instances may be live migrated, stopped or must stay fully available. Third, set up a change approval path and a set of maintenance windows. A partner can recommend a window and a rollback point, but your organization owns the business decisions on timing and on which risks to accept. Those decisions should be signed off by the people who carry the consequences of an outage.