# Planning for OpenStack 2026.1 (Gazpacho): What the Release Calendar Tells You About Upgrade Paths and Support Windows

- Link: https://thestackobserver.com/planning-for-openstack-2026-1-gazpacho-what-the-release-calendar-tells-you-about-upgrade-paths-and-support-windows/
- Published: 2026-03-03T08:02:03-05:00
- Author: Stackxx

OpenStack conversations often oscillate between two extremes: either “it’s legacy”
or “it’s the backbone of sovereign cloud.” The reality is that OpenStack is still
very alive — but it’s run by teams who care deeply about _release planning_, not
hype. If you operate OpenStack, the release calendar is one of your best operational
tools.

The official OpenStack Releases site lays out the current series, their phases, 
and key dates. This week is a good time to look at it because the next cycle, **
2026.1 (Gazpacho)**, is on the horizon with an estimated initial release date of**
2026-04-01**.

## OpenStack’s cadence in one sentence

OpenStack releases on roughly a 6‑month schedule, and after the initial release 
the ecosystem continues with stable point releases and maintenance phases. That’s
normal for infrastructure — but it means your upgrade planning needs to think in
terms of **phases**, not just “versions.”

## Maintenance phases matter more than version numbers

When the releases site shows a series as “Development,” “Maintained,” “Unmaintained,”
or “End Of Life,” it’s telling you what kind of upstream support posture you can
expect. In practical terms:

 * **Maintained**: stable branches get fixes and point releases; you can justify
   staying on the branch while planning your next step.
 * **Unmaintained**: you’re increasingly on your own; security and bug fix velocity
   drops.
 * **EOL**: you should have already moved; risk accumulates quickly.

For large private clouds, the cost of upgrading is real — but so is the cost of 
lingering past the point where you get meaningful upstream fixes.

## SLURP: why some releases are special for upgrades

The releases site also flags which releases use the “Skip Level Upgrade Release 
Process” (SLURP). SLURP releases matter because they define officially supported
upgrade paths that can skip a release. This is a pragmatic recognition that not 
every operator upgrades every six months.

If you’re planning upgrades for 2026, you should explicitly map your current series
to your target series and determine whether the path is adjacent-only or SLURP-enabled.
Your vendor’s distribution and your deployment tooling (Kolla, OpenStack-Ansible,
Juju, etc.) will also influence how smooth that path is.

## How to use the release calendar as an operator

Operators should treat the OpenStack release calendar like a product roadmap with
operational constraints. A simple process looks like this:

 * **Pick your target series** (for many teams, Gazpacho is the next major waypoint).
 * **Identify your current support posture**: are you on a maintained or unmaintained
   branch?
 * **Align with your vendor**: distribution packaging lag is real; upstream dates
   aren’t always your installable dates.
 * **Schedule upgrades around business windows**: treat control plane upgrades like
   major platform events.
 * **Plan for iterative validation**: upgrade one cell/region first when possible.

## Why this connects to “sovereign cloud” conversations

OpenInfra messaging increasingly centers on sovereignty, locality, and avoiding 
lock-in — especially as geopolitical and data residency pressures increase. But 
sovereignty isn’t just a procurement decision. It’s an operational posture: you 
need a predictable upgrade path, a supportable security story, and a clear lifecycle
plan for your core cloud control plane.

That’s why the boring stuff (calendars, phases, release processes) is actually the
most important part of the OpenStack story in 2026.

## What to do next if you’re targeting Gazpacho

 * **Subscribe to the combined release calendar** so changes aren’t surprises.
 * **Review your current series** and confirm whether it’s maintained.
 * **Start a lab upgrade rehearsal** now; don’t wait for the initial release date.
 * **Inventory integrations**: external auth, storage backends, SDN, and any custom
   automation.

## Sources

 * [OpenStack Releases (release series, phases, calendars)](https://releases.openstack.org/)
 * [OpenInfra Foundation: Inside Open Infrastructure (February 2026)](https://openinfra.org/blog/openinfra-newsletter-february-2026)