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.
Leave a Reply