# OpenStack 2026.1 ‘Gazpacho’ Is in Development: How to Plan an Upgrade Path Without Surprises

- Link: https://thestackobserver.com/openstack-2026-1-gazpacho-is-in-development-how-to-plan-an-upgrade-path-without-surprises/
- Published: 2026-02-27T08:35:45-05:00
- Author: Stackxx

OpenStack isn’t one product—it’s a coordinated ecosystem of services, libraries,
and deployment tooling. That’s great for flexibility, but it means operators need
a reliable release process to avoid “upgrade roulette.” The OpenStack releases site
provides a deceptively simple view into that process: a table of release series,
their status, and key dates.

Right now, the table shows **OpenStack 2026.1 ‘Gazpacho’** in **Development**, with
an estimated initial release date of **2026-04-01**. If you operate an OpenStack-
based private cloud, that single row is useful—but only if you know how to translate
it into an actionable plan.

## What the release series table actually means

The release table is a coordination artifact: it describes the lifecycle of a named
series, not the detailed release schedule of every single deliverable. In other 
words: it’s a map, not the terrain.

Still, the lifecycle phases are meaningful:

 * **Development**: the series is being built; new features are being merged; the
   release team is coordinating milestones.
 * **Maintained**: stable branches exist; point releases ship; operators can expect
   fixes without adopting a whole new series.
 * **Unmaintained / EOL**: you’re on borrowed time; vendors and community attention
   shift elsewhere.

For Gazpacho, “Development” is the signal that now is the right moment for operators
to do three things: (1) watch the schedule, (2) validate upgrade tooling in staging,
and (3) decide whether you’re targeting Gazpacho or the subsequent SLURP series 
for your next major jump.

## SLURP: the upgrade story hidden in parentheses

You’ll notice some releases are marked “(SLURP)”—the **Skip Level Upgrade Release
Process**. In plain terms, SLURP releases are intended to support upgrade paths 
that skip intermediate releases. That’s huge for real-world operators, because not
every organization can upgrade every six months.

When you’re planning multi-year maintenance, SLURP is one of the only “community-
level” guarantees that maps directly to operations:

 * If you’re behind, you want your next landing zone to be a SLURP release when 
   possible.
 * If your internal change windows are slow, you should align upgrades to SLURP 
   milestones.
 * If you depend on vendor distributions, check how they map their support timelines
   to SLURP and non-SLURP series.

## How to plan a Gazpacho upgrade without surprises

The most common OpenStack upgrade failures aren’t “a feature changed.” They’re ecosystem
mismatches: deployment tooling, driver compatibility, database migrations, and operational
playbooks that weren’t rehearsed.

A practical plan looks like this:

### 1) Choose an upgrade target based on your operational tempo

If you can upgrade yearly, you can track adjacent releases. If you upgrade every
18–24 months, you should bias toward SLURP releases as your “major” upgrade anchors
and treat other releases as optional.

### 2) Treat the control plane and data plane as separate risk domains

Operators often conflate them. Control plane upgrades (Keystone, Nova API, Neutron
API) have different blast radii than hypervisor and storage rollouts. Build upgrade
runbooks that can pause between these phases.

### 3) Run a full “day 2” rehearsal, not just an install

Staging should prove: rolling restarts, credential rotation, quota enforcement, 
backups/restore, and incident workflows. If your staging environment can’t prove
those, it’s not staging—it’s a demo.

### 4) Audit integrations and drivers early

Networking and storage drivers are where upgrades go to die. Validate compatibility
statements and test the exact combinations you run (kernel, hypervisor, NICs, storage
backends).

## OpenInfra’s ‘digital sovereignty’ messaging meets operator reality

The OpenInfra community has been emphasizing themes like **digital sovereignty**
and avoiding vendor lock-in. That resonates politically, but it also has an operational
interpretation: if you want sovereignty, you need _operational ownership_. That 
means you must own your upgrade discipline, your security posture, and your automation—
not just your licensing terms.

Release planning is the unglamorous foundation of that ownership. The Gazpacho series
is a reminder that OpenStack’s cadence is predictable; your job is to make your 
organization predictable enough to take advantage of it.

## Sources

 * [OpenStack Releases: Release Series](https://releases.openstack.org/)
 * [OpenInfra Foundation Blog](https://openinfra.org/blog/)