Back in April we wrote up the OpenStack 2026.1 “Gazpacho” release: what was in it, and what it meant for enterprises running managed OpenStack. That post ended with a sentence that is easy to write and harder to cash: we are planning the Gazpacho upgrade path now.
On August 19 we ran it. Every service, every host, one morning.
This post is the receipt. We are publishing the numbers because the upgrade is the part of managed infrastructure that customers can never see and have to trust, and because “we handle upgrades” is a claim every provider makes and almost none of them quantify.
The number that matters
Thirty-three running instances. None in an error state. None restarted.
Through the entire cutover, every virtual machine on the platform stayed ACTIVE. Not “recovered quickly.” Not “restarted cleanly.” The hypervisor process serving those VMs was never restarted, which means the workloads did not pause, did not reboot, and did not need anything from the people who own them. If you had been logged into a server on our platform that morning, the upgrade would have been invisible to you.
That is the entire design goal of a control-plane upgrade, and it is worth being precise about why it is achievable. In OpenStack the control plane and the workloads are genuinely separable. The APIs that create, attach, and route can be replaced underneath running instances, because the instances are not being served by those APIs once they are up. An upgrade done properly touches the management layer and leaves the compute layer alone. An upgrade done improperly takes the workloads with it. The difference is entirely in the sequencing and the preparation, which is what you are actually buying when you buy managed infrastructure.
The window
We compressed the cutover into a single same-day window rather than spreading it over a week of partial states. Core services moved between 07:50 and 10:22 UTC, with the load-balancer tail finishing shortly after.
During the load-balancer phase, which is the part of the sequence where the shared API address moves between hosts, we sampled availability continuously: 714 probe samples across the window, with two interruptions totalling roughly two seconds, both at the moment the address handed over. For comparison, the same phase in our previous major upgrade produced about twice that. So the API was reachable for effectively the entire morning, and the two-second gaps landed exactly where the architecture says they should.
What actually moved
Every integrated service went to 2026.1 across all six hosts: identity, compute, networking, block storage, images, placement, load balancing, key management, orchestration, and DNS. Two changes inside that list are worth calling out because they are the kind of thing that turns a routine upgrade into an incident when it is not planned for.
The message broker changed its metadata store. RabbitMQ moved from 4.1 to 4.2.9, and we took the opportunity to migrate its cluster metadata onto the newer store in the same window rather than deferring it into a second maintenance event. That is the more aggressive of the two options and we chose it deliberately: a deferred migration is a second window, and a second window is a second chance to be wrong. It came up clean, three nodes, no partitions, with the queue configuration we run deliberately left intact.
Identity changed shape. The 2026.1 identity service splits its API and its federation handling differently than previous releases did. That is precisely the sort of structural change that quietly breaks single sign-on for everyone at once, so we did not meet it for the first time during the cutover. We rehearsed the new arrangement on the deployment path the morning before, and it came up correct, with our security enforcement applied from first start rather than bolted on afterward.
Neither of those is a feature a customer will ever ask about. Both are the reason the morning was boring.
Preparation is most of it
The cutover itself took a morning. The work that made it take a morning did not.
Before the window we cut our internal release branches by merging upstream into the deployment-specific work we carry, verified that every one of our carried changes still applied, built and inspected the resulting container images, and rolled the control plane onto the latest previous-release build first as a dress rehearsal of the exact deployment path we were about to use. We also ran automated pre-flight checks, which caught several configuration gaps that would otherwise have surfaced mid-cutover with the cluster half-moved.
That last point is the practical one. Every gap we found before the window was a five-minute fix. The same gap found during the window is an incident. The pre-flight checks are boring, repetitive, and the single highest-leverage thing in the entire runbook.
We also treat the upgrade path as one hop at a time. The release cadence offers a way to skip intermediate versions, and there is a real argument for it if upgrades are painful enough that you want fewer of them. We take the opposite position: if each upgrade is routine, doing them more often means less change per window, less divergence from upstream, and security fixes that arrive on the current branch rather than being backported into something old. Staying close to upstream is a security posture, not just a tidiness preference.
FIPS came along for the ride
Every service now runs on our FIPS-enabled image set, built on Ubuntu 24.04 with FIPS 140-3 validated cryptography (CMVP certificate #5115). That was already true before the upgrade and it is still true after it, which is the actual achievement: a major version change did not become an excuse for a temporary exception to the security baseline.
FIPS posture is verified automatically as part of deployment rather than assumed, so the posture cannot drift quietly between windows. After the cutover we swept all six hosts and confirmed the state held across every running container on the platform.
After the window
Post-upgrade we swept the fleet for anything not running, found nothing, and confirmed every service was on the new release except a small number of deliberate pins we control. We spot-checked live migration by moving a running instance between hosts and confirming it kept serving.
We re-ran our load and stability harness against the upgraded cluster as part of acceptance. And we rebuilt our managed application platform on the new release from scratch: every managed app type we offer, including Managed OpenCloud and Managed Odoo, was provisioned through the production path, verified, and torn down again, so that the first customer deployment after the upgrade was not also the first test of it.
Why publish this
Because “we manage it for you” is not a differentiator when everyone says it. What a maintenance window costs you is a differentiator, and it is measurable.
If you are running OpenStack yourself, the honest version is that the software is not the hard part. The hard part is doing this on a schedule, with preparation nobody sees, on infrastructure other people depend on, without it becoming an event. If you would rather that be someone else’s morning, that is the service.
If you are evaluating providers, ask them the question we just answered in public: the last time you did a major version upgrade, how many customer workloads restarted, and how many minutes of guest downtime did it cost?
Talk to us about what running your workloads on a managed, current, FIPS 140-3 validated OpenStack platform would look like. Every engagement is scoped and quoted directly. Get in touch.