Field notes / Latest
Engineering notes from operating open infrastructure: the failures, design decisions, and upstream work that make open infrastructure better.
Browse all field notes
Not sure whether to upgrade or migrate your OpenStack cloud? Learn how to evaluate architecture, hardware, storage, networking, technical debt, and operational complexity.
Read field note
Data residency isn't the same as data sovereignty. Five questions that actually determine who controls your workload, and why the answer matters more than where the servers sit.
Read field note
Learn how identity, network security, data protection, and auditability help private cloud teams support compliance requirements.
Read field note
Not sure whether to upgrade or migrate your OpenStack cloud? Learn how to evaluate architecture, hardware, storage, networking, technical debt, and operational complexity.
When an OpenStack environment becomes difficult to maintain, the obvious diagnosis is often: “We need to upgrade.”
Sometimes that is exactly right. An aging OpenStack release can create support, security, compatibility, and operational concerns. But OpenStack is only one layer of a private cloud. The underlying problem may instead be aging servers, storage contention, network design, accumulated customizations, weak automation, or workload requirements that have changed since the cloud was built.
That distinction matters. An upgrade can move the control plane and services onto a newer release. It cannot make undersized hardware faster, redesign an unsuitable storage architecture, or remove years of operational technical debt by itself.
The better starting question is:
Which parts of this platform no longer meet our requirements?
Private cloud problems often surface through OpenStack because that is where operators interact with the infrastructure. A slow instance build may look like a Nova problem. Failed volume operations may appear to be a Cinder problem. Intermittent connectivity may first be investigated in Neutron.
But the root cause may sit elsewhere.
Slow provisioning can result from image-transfer bottlenecks, overloaded storage, database latency, message-queue pressure, or compute placement constraints. Network instability can come from physical switching, MTU inconsistency, or oversubscribed links.
Start by documenting the symptoms that triggered the upgrade discussion:
If software lifecycle is the primary problem, an upgrade may be enough. If several infrastructure layers fail the same assessment, the scope is probably broader.
An upgrade is usually appropriate when the private cloud remains fundamentally healthy.
Typical conditions include sound architecture, viable hardware, adequate capacity, acceptable storage and network performance, maintainable integrations, and repeatable deployment automation. In that case, the main problem may simply be the age or maintenance status of the OpenStack release.
OpenStack is developed on roughly six-month release cycles, and its release process includes designated Skip Level Upgrade Release Process (SLURP) releases. The official OpenStack release documentation explains that supported paths can exist between SLURP releases as well as between adjacent releases. That does not mean every service or deployment can simply skip an intermediate version directly. Service-level constraints, operating systems, databases, message queues, and deployment tooling still determine the executable upgrade sequence.
Before approving the upgrade, evaluate several areas.
Current release and target path. Identify the source and target releases, required intermediate steps, deprecated configuration, database migrations, operating-system dependencies, and deployment-tool requirements.
Control-plane health. Resolve existing database replication, RabbitMQ, certificate, API, or configuration-drift problems before adding upgrade risk.
Capacity headroom. Maintenance can temporarily reduce available compute or service capacity. Confirm that the cloud can tolerate the planned sequence.
Integration compatibility. Validate identity, monitoring, backup, automation, SDN, storage drivers, clients, and other integrations against the target environment.
Recovery. Back up the required databases and configuration and test restoration procedures. The current Nova upgrade documentation, for example, explicitly calls for a database backup and notes that Nova database downgrade is not supported.
If those checks are favorable, migration may add complexity without solving another problem.
A broader modernization or migration assessment becomes appropriate when several constraints exist below or around OpenStack.
Repeated performance or reliability incidents are one warning sign, especially when root causes point to storage latency, compute saturation, failing hardware, or network bottlenecks. Changing the OpenStack version will not remove those limits.
Extensive customization is another. Private patches, nonstandard service changes, old plugins, tightly coupled scripts, or integrations with unclear ownership can make every upgrade a bespoke engineering exercise.
Hardware lifecycle can change the decision too. If much of the compute, network, or storage estate already needs replacement, preserving the current physical architecture may offer limited value.
Other warning signs include:
No single symptom automatically means “rebuild.” The pattern matters. Several reinforcing constraints usually indicate a platform problem rather than only a release problem.
These options describe different scopes of change.
An upgrade moves OpenStack services to a newer release while preserving most of the current infrastructure and architecture.
It fits when software lifecycle is the main constraint and the surrounding platform remains fit for purpose.
Modernization retains OpenStack but changes important parts of the surrounding platform or operating model.
That might include refreshing compute hardware, redesigning storage, improving networking, removing custom patches, strengthening observability, or adopting more repeatable deployment automation.
Modernization can therefore include an OpenStack upgrade without requiring workloads to leave OpenStack.
A migration moves workloads, data, services, or tenants to another environment.
The destination does not have to use different technology. An organization can migrate from a legacy OpenStack cloud into a newly designed OpenStack environment, including an on-premises or hosted private cloud.
This distinction matters: migrating an OpenStack environment does not necessarily mean abandoning OpenStack.
A rebuild creates a new target environment rather than incrementally changing the existing one.
It becomes reasonable when technical debt, unsupported components, or architectural constraints make in-place work disproportionately complex or risky.
The objective should be to choose the smallest scope of change that resolves the real constraints.
.png&w=3840&q=75)
Do not treat the matrix as a scorecard. The interaction between constraints matters more than the number of boxes checked.
An old release on healthy hardware with good automation and adequate storage can still be primarily an upgrade problem.
The same release on end-of-life servers with saturated storage, undocumented patches, and manually maintained networking is a platform problem.
OpenStack coordinates infrastructure; it does not replace the systems underneath it.
Consider inconsistent VM provisioning. Nova may be involved, but operators should also measure scheduler behavior, database performance, image-transfer time, storage latency, host capacity, and message-queue health.
The same principle applies elsewhere.
Cinder can manage volumes correctly while the storage backend struggles under recovery load. Neutron configuration can be valid while the physical network suffers from MTU inconsistency or insufficient bandwidth. Redundant OpenStack API services cannot compensate for single points of failure in databases, storage, power, or switching.
That is why the assessment should cover:
The platform should also be evaluated against where the organization is going—not only against the workloads it runs today.
A cloud can be technically healthy and still require modernization if future workload requirements have materially changed.
Whether the result is an upgrade or migration, start with discovery.
Inventory services, versions, hosts, hypervisors, storage backends, networks, integrations, custom configuration, automation, and important workloads. Map dependencies before changing production.
Then establish recoverability. Back up required databases and configuration, verify restoration, and define rollback or recovery criteria.
Rollback should not be assumed to mean simply reinstalling old packages. Schema and state changes may require restoring a known-good data state.
Test the planned path in a representative non-production environment where practical. The Kolla-Ansible operating documentation, for example, includes preparation such as updating deployment tooling and inventory, pulling target images, and running prechecks before an upgrade. Other deployment methods have their own requirements.
For migrations or larger modernization programs, group workloads by criticality, statefulness, dependencies, data volume, and downtime tolerance. Pilot lower-risk workloads first, validate the target environment, and move production systems in controlled phases.
Define acceptance criteria before each change. These may include:
Avoid promising zero downtime universally.
Nova supports rolling compute-service upgrades intended to minimize disruption, but a complete private cloud transition involves more than Nova. Actual workload interruption depends on architecture, deployment tooling, storage and networking changes, application behavior, and the chosen transition method.
If the architecture is healthy, capacity is sufficient, hardware remains viable, integrations are maintainable, and software lifecycle is the main concern, upgrade the OpenStack cloud you already have.
If OpenStack remains a good fit but hardware, storage, networking, automation, observability, or operating practices need significant work, modernize the platform while retaining OpenStack.
If several architectural constraints are difficult to correct safely in place, or future requirements demand a substantially different design, build a new target environment and migrate deliberately.
The goal is not to choose the largest project.
It is to avoid both extremes: rebuilding a healthy cloud unnecessarily and upgrading a platform whose fundamental limitations will remain afterward.
Organizations do not necessarily need to make that assessment alone. Experienced OpenStack engineers can help determine whether issues originate in the release itself or in the surrounding compute, storage, networking, hardware, automation, and operating model.
VEXXHOST designs, deploys, upgrades, migrates, and operates OpenStack-based private cloud infrastructure. Its own OpenStack Upgrade Playbook similarly emphasizes inventory, staging, capacity planning, observability, backups, and rollback preparation rather than treating an upgrade as an isolated version change.
If your OpenStack environment is aging or increasingly difficult to change safely, talk to VEXXHOST about assessing the architecture and identifying the most appropriate upgrade, modernization, or migration path.
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes
