# OpenStack heads toward 2026.1 ‘Gazpacho’: elections, service retirements, and what operators should watch

- Link: https://thestackobserver.com/openstack-heads-toward-2026-1-gazpacho-elections-service-retirements-and-what-operators-should-watch/
- Published: 2026-02-13T08:16:15-05:00
- Author: Stackxx

OpenStack’s story in 2026 is less about “is it alive?” and more about “how is it
evolving?” The OpenInfra community continues to ship on a predictable cadence, but
the signals that matter most to operators aren’t always in a single release note.
They show up in governance: election cycles, project health, and which services 
are getting the volunteer attention needed to stay vibrant.

Two recent OpenInfra newsletter updates highlight the themes: election season is
underway again (Technical Committee and Project Team Lead seats), and the community
is actively discussing the status of ancillary services as the OpenStack 2026.1 “
Gazpacho” cycle approaches.

## Why governance news is operational news

In OpenStack, the long tail of services matters. Operators rarely run “just Nova
+ Neutron.” They run storage, images, telemetry, logging, and often a set of integrated
operational tools. When a project’s maintainer base shrinks, it shows up as:

 * Slower bug fixes and security response
 * Backlogged reviews and less predictable releases
 * More divergence between distros and upstream
 * Higher long-term operational risk

That’s why election season and volunteer health should be tracked by operators the
same way they track CVEs.

## Service retirement and “at-risk” projects: what it means for your architecture

One newsletter note worth paying attention to: Monasca (monitoring as a service)
has been retired from OpenStack, and other services like Venus (log management) 
and Vitrage (root cause analysis) have been discussed as potentially inactive for
Gazpacho due to lack of volunteers.

Even if you’re not running these components today, the pattern is important: the
community is making explicit choices about what it can sustainably maintain. For
operators, that suggests a few pragmatic moves:

 * **Prefer well-supported primitives** for observability (e.g., OpenTelemetry, 
   Prometheus, Loki/Elastic) integrated around OpenStack rather than relying on 
   niche in-tree services.
 * **Plan for replacements** before you’re forced into them. “Retired” rarely breaks
   your cloud overnight, but it creates a future migration you’ll pay for later.
 * **Track downstream packaging** from your distro/vendor. Some vendors keep retired
   projects alive for customers, but that becomes a vendor-specific support dependency.

## OpenStack 2026.1 ‘Gazpacho’: what to watch (even before release day)

With Gazpacho scheduled for 2026, operators can use the lead-up period to reduce
upgrade pain. Focus on:

 * **Dependency hygiene**: Python base, messaging backends, database versions, and
   the distro story.
 * **API deprecations**: identify which components your workloads actually call (
   Nova, Neutron, Cinder, Glance) and verify client versions.
 * **Day-2 automation**: ensure your deployment tooling (Kolla-Ansible, OpenStack-
   Ansible, TripleO derivatives, vendor stacks) is tested against the upgrade path
   you intend.

The most expensive OpenStack upgrades are the ones you treat as “we’ll do it later.”
The second-most expensive are the ones where observability is bolted on after the
upgrade.

## Elections: why operators should care who wins

Technical Committee and PTL seats influence what gets prioritized, which deliverables
get attention, and where the community invests. Operators can treat elections as
a “roadmap input” moment:

 * If you rely on a project, consider participating in the community and supporting
   maintainers.
 * If you’ve adopted an OpenStack-adjacent project (like Kubernetes integration,
   OpenTelemetry, or Ceph), watch how the community frames those integrations.
 * If your enterprise depends on long-term stability, advocate for clear deprecation
   timelines and upgrade guidance.

## How this intersects with Kubernetes (and why that’s okay)

More organizations are running OpenStack and Kubernetes together: OpenStack as the
IaaS foundation and Kubernetes as the application platform. That hybrid approach
is no longer unusual — it’s often the best of both worlds.

For operators, the implication is: keep OpenStack’s core strong (compute/network/
storage), and be willing to modernize the surrounding ecosystem (observability, 
policy, workload scheduling) with best-of-breed cloud native tools.

## Bottom line

OpenStack’s Gazpacho cycle is a good moment to reassess not just versions, but assumptions:
which projects are healthy, which are fading, and which external tools you should
standardize on. Operators who treat governance signals as operational signals tend
to avoid last-minute migrations.

## Sources

 * [Inside Open Infrastructure: January 2026 (elections, community notes)](https://openinfra.org/blog/openinfra-newsletter-january-2026/)
 * [Inside Open Infrastructure: December 2025 (service status notes)](https://openinfra.org/blog/openinfra-newsletter-december-2025/)