OpenStack Gazpacho (2026.1): What Changes for Production
A technical analysis of OpenStack Gazpacho (2026.1), covering compute, networking, storage, bare metal, API compatibility, and production upgrade considerations.
On this page
OpenStack 2026.1, codenamed Gazpacho, delivers a significant set of improvements across compute, networking, block storage, bare metal provisioning, and shared filesystems. Released on April 1, 2026, Gazpacho is a Skip-Level Upgrade Release (SLURP), making it an important lifecycle milestone for organizations operating production private clouds.
The release introduces parallel live migration connections and improved virtual machine I/O handling in Nova, deeper BGP integration with OVN in Neutron, expanded Redfish provisioning capabilities in Ironic, and new storage functionality across Cinder and Manila.
Beyond individual features, Gazpacho also advances OpenStack’s transition away from Eventlet-based concurrency. Several services introduce or adopt native Python threading, but the maturity differs by service: Nova’s API, metadata, and scheduler services now default to native threading, while other services offer it as an experimental or technology-preview option. Operators must distinguish application upgrades from runtime architecture changes.
For production environments, the primary considerations are API compatibility, service concurrency behavior, networking configuration, database migrations, and the validation of deployment-specific upgrade paths. Gazpacho provides meaningful capabilities, but these changes require deliberate integration and testing rather than assuming that existing configurations will behave identically after an upgrade.
Release at a Glance
| Property | Details |
|---|---|
| Release Name | Gazpacho |
| Version | 2026.1 |
| Upstream Release Date | April 1, 2026 |
| Release Type | SLURP (Skip-Level Upgrade Release) |
| Release Status | Maintained |
| Successor Release | 2026.2 Hibiscus (released September 30, 2026; not a SLURP release). The next SLURP release is 2027.1. |
| Official Release Documentation | OpenStack Gazpacho |
| Release Highlights | Gazpacho Release Highlights |
As a SLURP release, Gazpacho supports OpenStack’s coordinated skip-level upgrade strategy. This does not mean that every deployment framework, storage driver, networking backend, or third-party integration automatically supports skipping an intermediate release.
Operators must validate the upgrade path against the documentation for their chosen deployment framework and the OpenStack services they operate.
The release highlights page is compiled directly from project-team input and describes itself as unprocessed. Where this article relies on it alone, the service-specific release notes and documentation should be treated as authoritative.
Key Technical Changes
Nova — Compute
Parallel Live Migration Connections
What changed
Nova introduces the [libvirt] live_migration_parallel_connections configuration option, enabling multiple connections for transferring virtual machine memory during live migration.
The feature is disabled by default: parallel migration is only used when the option is set to a value higher than 1. Previously, memory transfer could be constrained by the characteristics of a single migration connection, and parallel connections provide an additional mechanism for improving migration throughput.
Why it matters
Live migration is central to compute-node maintenance, hardware lifecycle management, and workload mobility in production clouds.
Parallel memory transfer can be useful for instances with large memory footprints, particularly when the underlying network has sufficient bandwidth.
Operational impact
Operators should evaluate migration performance under representative workloads before enabling or tuning parallel connections.
Relevant considerations include:
- Available migration network bandwidth.
- Concurrent migration limits. Nova now deprecates the value
0(“unlimited”) for[DEFAULT]max_concurrent_live_migrationsand recommends this option when faster migrations are needed. - QEMU and libvirt compatibility. QEMU versions prior to 10.1.0 cannot combine multifd with post-copy migration, so enabling both together on older QEMU versions is disallowed.
- Migration performance under sustained memory-write activity.
The existence of parallel migration support does not guarantee shorter migration times for every workload.
Source: Nova 2026.1 Release Notes
IOThread Enabled by Default
What changed
Nova now enables one QEMU IOThread per virtual machine by default, separating disk I/O processing from virtual CPU execution.
For real-time instances, the IOThread is pinned to the same cores as the emulator thread to avoid interfering with dedicated virtual CPUs.
Why it matters
Separating disk I/O processing from guest vCPU threads can improve workload isolation and reduce I/O-related contention in certain deployment scenarios.
Operational impact
Operators should validate CPU allocation, emulator-thread placement, and performance behavior for latency-sensitive workloads.
The impact will depend on the hypervisor configuration, storage backend, and workload characteristics.
Source: Nova 2026.1 Release Notes
Asynchronous Volume Attachment
What changed
Starting with Nova API microversion 2.101, volume attachment becomes asynchronous. The API returns HTTP 202 Accepted rather than waiting for the operation to complete. Previously, the call returned HTTP 200 with a volumeAttachment object that included the device name.
The attachment process is offloaded to Nova’s conductor service. Nova’s release notes explain that the device name could not be guaranteed by the current drivers, and that reserving it could block the API thread.
Why it matters
An accepted API request no longer necessarily indicates that the volume is fully attached and ready for use, and the response no longer carries the device name.
Operational impact
Automation that uses microversion 2.101 or later must distinguish request acceptance from operation completion.
Clients should check the resulting attachment state before performing dependent actions, and should not depend on the device name being present in the attach response.
This is particularly important for orchestration workflows that immediately mount, format, or use newly attached volumes.
Source: Nova 2026.1 Release Notes
vTPM Live Migration
What changed
Nova introduces support for live migration of instances using virtual TPM devices when the host TPM secret security mode is selected.
The flavor extra spec hw:tpm_secret_security=host enables the relevant behavior. Operators create the flavors, and can restrict which modes their compute hosts support with the [libvirt]supported_tpm_secret_security option.
In host mode, the TPM secret is persisted in libvirt and transferred over RPC to the destination during migration. The legacy user secret security mode does not support live migration in this release.
Why it matters
Virtual TPM functionality is increasingly relevant for operating systems and workloads requiring TPM-backed security capabilities.
Operational impact
Operators must review the security implications of the host secret mode and ensure that the necessary Barbican permissions and migration prerequisites are satisfied.
Existing instances can opt in by resizing to a flavor that sets hw:tpm_secret_security=host. Because of Barbican secret ownership constraints, this resize must be performed by the instance owner unless the administrator has been granted appropriate ACLs in Barbican.
Source: Nova 2026.1 Release Notes
Neutron — Networking
OVN BGP Integration
What changed
Gazpacho integrates OVN BGP capabilities into Neutron’s OVN driver.
This extends the integration between Neutron-managed logical networking and BGP-based connectivity to external infrastructure.
Why it matters
BGP integration is relevant to private cloud environments that use routed data center fabrics, external network advertisements, and automated network provisioning.
Operational impact
Operators should evaluate the applicable Neutron and OVN configuration requirements, routing architecture, and interaction with their physical network infrastructure.
The release highlights establish the integration, but production deployment details must be validated against the Neutron documentation for the selected topology.
Source: Gazpacho Release Highlights
External Port Routing and Addressing
What changed
ML2/OVN gains support for north/south routing involving external ports, including SR-IOV and bare metal use cases.
The release also adds support for allowed address pairs using virtual MAC addresses. This requires OVN v26.03, which adds VRRPv3 support. With older OVN versions, port security for such an address pair fails with an invalid syntax error and the port does not accept traffic for that IP and MAC combination, as before. Neutron 28.0.1 also validates that the virtual MAC conforms to the RFC 5798 VRRP ranges (00:00:5e:00:01:XX for IPv4 or 00:00:5e:00:02:XX for IPv6).
Why it matters
These capabilities broaden the networking scenarios supported by OVN, particularly for workloads requiring direct hardware access or more specialized external connectivity.
Operational impact
Operators should validate OVN version requirements, port-binding behavior, physical network mappings, security policies, and routing behavior before adopting these capabilities.
Sources:
Network IP Availability Visibility
What changed
Neutron introduces the network-ip-availability-details API extension, which provides additional information about IP address consumption within subnets and allocation pools.
Why it matters
Better visibility into address utilization helps operators identify capacity constraints before they affect tenant provisioning.
Operational impact
This information can support IP address management, capacity dashboards, and operational monitoring.
Source: Neutron 2026.1 Release Notes
Cinder — Block Storage
New Storage Drivers and Backend Capabilities
What changed
Cinder introduces new drivers for VAST Data and VMstore (NFS) storage systems.
Additional driver enhancements include Dell PowerStore metro volume support and an updated REST token refresh mechanism in the Dell PowerFlex driver, intended to avoid downtime in a PowerFlex Management Platform failure scenario.
Why it matters
These changes expand the storage platforms and configurations that can be integrated into OpenStack environments.
Operational impact
Operators should validate backend-specific requirements, supported capabilities, and driver compatibility before introducing a new storage backend.
Driver availability does not imply that every advanced storage capability is supported identically across backends.
Source: Cinder 2026.1 Release Notes
Volume Disk Geometry
What changed
Cinder adds a disk_geometry configuration option that allows volume drivers to advertise logical and physical block sizes to guest systems.
The option is unset by default, which matches the behavior of previous releases. The recommended value for HDD-backed storage is 512e (logical 512, physical 4096 bytes). Guests need a VirtIO driver from 2019 or newer to use the feature.
Why it matters
Accurate disk geometry information can help guest operating systems and applications align their I/O behavior with the underlying storage. The effect is most visible for Windows guests, which would otherwise submit 512-byte I/O, and on back ends such as Ceph where aligned 4k requests avoid extra read-modify-update cycles.
Operational impact
The configured value applies whenever a volume is attached, but existing virtual machines may require their libvirt configuration to be regenerated before the new geometry becomes visible.
Depending on the workflow, this can involve detaching and reattaching the volume, cold migrating the instance, or live migrating it. Guests may also require a reboot to recognize the updated information.
Operators should plan these changes carefully rather than assuming that updating the storage configuration immediately changes existing guest-visible disk properties.
Source: Cinder 2026.1 Release Notes
Ironic — Bare Metal Provisioning
Redfish Virtual Media over NFS and CIFS
What changed
Ironic extends Redfish Virtual Media boot support to NFS and CIFS/SMB transport protocols.
The driver can automatically detect supported transport protocols using the capabilities reported by the baseboard management controller (BMC).
Operators can configure shares through the [nfs] and [cifs] configuration sections, with per-node overrides available through driver_info.
Why it matters
Bare metal provisioning frequently depends on vendor-specific BMC capabilities and the accessibility of boot images.
Additional transport options provide more flexibility when integrating heterogeneous server hardware.
Operational impact
Ironic does not deploy or operate the NFS or CIFS services itself.
Operators remain responsible for providing the file shares, configuring access, and ensuring that the BMC can reach the selected transport endpoint.
Source: Ironic 2026.1 Release Notes
Automatic Deployment Interface Selection
What changed
Ironic introduces an autodetect deploy interface that selects a suitable concrete deployment interface based on node configuration and image metadata.
The autodetect interface is enabled by default in enabled_deploy_interfaces, and its default candidate list is now ['ramdisk', 'bootc', 'direct']. Operators who have not set autodetect_deploy_interfaces explicitly will therefore have the ramdisk interface auto-selected when a Glance image_source carries the appropriate metadata.
A new noop deploy interface also allows existing systems to be represented as active nodes without performing an operating system deployment.
Why it matters
These capabilities are useful when onboarding pre-existing bare metal systems or managing heterogeneous hardware environments.
Operational impact
Operators should validate the interface selection behavior, the default candidate list, and inventory assumptions before adopting automatic deployment selection.
Sources:
Standalone Bare Metal Networking
What changed
Ironic introduces a standalone ironic-networking service capable of managing physical network switch configuration without requiring Neutron. Per Ironic’s release notes, it provides basic VLAN configuration on remote switches using networking-generic-switch, and the interface is marked experimental to allow for feedback before it becomes stable.
The broader bare metal networking ecosystem also gains additional support for VXLAN and Geneve overlay scenarios through networking-generic-switch and networking-baremetal.
Why it matters
These capabilities are relevant to environments using Ironic independently from a full OpenStack cloud deployment.
Operational impact
Operators should assess the networking service’s experimental status, supported switch integrations, configuration model, and operational responsibilities before deploying it in production.
Sources:
Manila — Shared Filesystems
Share Quality of Service
What changed
Manila introduces QoS types and QoS type specifications, allowing administrators to define performance constraints such as throughput or IOPS limits.
Why it matters
QoS capabilities are relevant to multi-tenant file storage environments where workloads compete for shared storage resources.
Operational impact
Operators should confirm which QoS capabilities are supported by their storage drivers and backends before making performance guarantees to tenants.
Source: Gazpacho Release Highlights
Share Replica Metadata
What changed
Users can now set and unset metadata on share replicas.
Storage drivers can use this metadata to inform replication behavior.
Why it matters
This provides additional flexibility for storage workflows involving replication policies and backend-specific behavior.
Operational impact
Operators should validate driver support and avoid assuming that metadata has identical semantics across storage backends.
Source: Gazpacho Release Highlights
Horizon — Dashboard
Live Migration and Dashboard Improvements
What changed
Horizon adds support for Nova live migration microversion 2.30.
The Key Pairs page has also been rewritten using Python/Django while retaining the functionality of its previous AngularJS implementation.
A new configuration option helps avoid resource-intensive full listings of containers and objects in the Swift dashboard.
Why it matters
These changes improve integration with Nova capabilities and address operational concerns around dashboard resource consumption.
Operational impact
Operators should validate Horizon functionality against their configured Nova API microversions and test any customized dashboard integrations.
Source: Gazpacho Release Highlights
Cyborg and Designate — Service Modernization
What changed
Cyborg migrates its services to native Python threading and validates its Placement resource provider at agent startup, with automatic retry and backoff.
Designate also completes its migration from Eventlet to native Python threading across all services.
Why it matters
The transition away from Eventlet is a significant architectural change across the OpenStack ecosystem.
Native threading reduces reliance on legacy cooperative concurrency mechanisms, but the impact on operational behavior must be evaluated for each service.
Operational impact
Operators should test startup behavior, health monitoring, service dependencies, and any custom integrations that rely on assumptions about the previous concurrency model.
Source: Gazpacho Release Highlights
Deprecations, Removals, and Compatibility
Gazpacho includes changes that require particular attention from operators maintaining existing OpenStack deployments.
Nova API and Deployment Changes
Nova introduces several API and deployment changes:
- API microversion
2.101makes volume attachment asynchronous and no longer returns the device name in the response. - API microversion
2.102allows searching flavors by name (for exampleGET /flavors?name=gpu). It also removes therxtx_factorandOS-FLV-DISABLED:disabledfields from all flavor responses and stops acceptingrxtx_factorwhen creating a server. In addition, all APIs now reject unknown query-string parameters with HTTP 400, building on work started in microversion 2.75. This last change is not limited to flavors and can affect any client that sends unrecognized parameters. - API microversion
2.103deprecates the undocumented/os-volumes_bootAPI, returning HTTP 404 for requests using this microversion or later. - The
nova-api-wsgiandnova-metadata-wsgiscripts have been removed. Deployment tooling must reference the Python module pathsnova.wsgi.osapi_computeandnova.wsgi.metadata(for WSGI servers such as gunicorn or uWSGI), or provide its own.wsgiscript (for mod_wsgi). - Several concurrency-related defaults change.
[DEFAULT]sync_power_state_thread_pool_sizedrops from 1000 to 5, and the value0formax_concurrent_builds,max_concurrent_snapshots, andmax_concurrent_live_migrationsnow means different limits depending on the concurrency mode (and is deprecated). Operators who stay on Eventlet and rely on higher values should configure them explicitly before upgrading.
Operators should inspect API consumers and deployment automation for dependencies on these interfaces.
Source: Nova 2026.1 Release Notes
WSGI Entry Points in Neutron and Cinder
The same WSGI script removal applies beyond Nova. The neutron-api script has been removed in favor of the neutron.wsgi.api module path, and cinder-wsgi has been removed in favor of cinder.wsgi.api. Deployment tooling should be reviewed for all three services.
Sources:
Neutron Policy and OVN Changes
Neutron’s default RBAC policies for several port actions that require network ownership no longer include PROJECT_MANAGER. Deployments with customized policy files should review those rules.
The RBAC policy target_tenant value is now validated and must be either * or a valid UUID. Neutron provides an upgrade check for existing policies that would be silently ineffective, which can be run with neutron-status upgrade check before upgrading.
Support for OVN versions older than v20.03.0 has been removed, and usage of tenant_id in API policy rules is deprecated for removal in 2027.1 in favor of project_id.
Source: Neutron 2026.1 Release Notes
Cinder Removals
Cinder removes the Windows iSCSI and Windows SMB volume drivers, and support for running Cinder services on Windows operating systems has been removed.
Source: Cinder 2026.1 Release Notes
Manila API and CLI Removals
The Manila v1 API and the Manila shell utility have been removed.
Operators should audit scripts and integrations that still depend on these legacy interfaces and migrate them to supported APIs and tooling.
Source: Gazpacho Release Highlights
Ironic Compatibility and Database Changes
Ironic removes the experimental capability to pass OVN VTEP connection information through to Neutron.
The change is associated with Ironic API version 1.104.
Operators using this experimental integration should review their network provisioning workflows before upgrading.
Ironic also introduces changes that require upgrade planning:
- Database encoding migration. Ironic now requires
UTF8MB4encoding for MySQL/MariaDB, which means MySQL 8.0+ or MariaDB 10.3+. The migration converts existing tables and locks each table while it is rewritten. Ironic’s release notes advise planning for downtime and testing the upgrade on a copy of production data. - Removed interfaces. The deprecated
inspectorinspect interface, theiloconsole interface, and all shellinabox-based console functionality have been removed. - Deprecated hardware type. The Fujitsu
irmchardware type is deprecated for removal. - Security hardening. Ironic’s 2026.1 series includes several security fixes, some with CVE identifiers, and disables some functionality by default (for example the IPMI
send_rawvendor-passthru step). Operators should review the security sections of the release notes and apply the latest stable point release.
Source: Ironic 2026.1 Release Notes
Freezer Storage Backend Deprecation
Freezer now defaults to SQLAlchemy for API storage.
Its Elasticsearch database storage backend is deprecated and scheduled for removal in the following release.
Operators using Elasticsearch for Freezer metadata should plan a supported migration.
Source: Gazpacho Release Highlights
Native Threading Transition
Native threading is not at the same maturity level across OpenStack projects:
- Nova API, metadata, and scheduler: the default concurrency mode is now native threading, and Eventlet can still be selected per service.
- Nova compute and conductor: native threading is an experimental feature that is disabled by default. Nova asks operators to test it in pre-production before enabling it in production.
- Manila: native threading for the scheduler, data, and share services is introduced as a technology preview and is not recommended for production use. The
manila-apiservice is unaffected when deployed behind an external WSGI server. - Cyborg and Designate: both have completed their migration to native threading.
The official Nova release notes recommend separating the OpenStack version upgrade from the concurrency-mode migration to reduce operational risk.
Sources:
Upgrade Considerations for Production
1. Validate the SLURP Upgrade Path
Gazpacho is a SLURP release, allowing supported skip-level upgrade paths within OpenStack’s coordinated lifecycle model.
Nova’s release notes explicitly discuss the possibility of upgrading from 2025.1 Epoxy directly to 2026.1 Gazpacho, skipping 2025.2 Flamingo. Ironic’s release notes similarly state that it supports upgrades directly from 2025.1.
However, operators must validate support across their complete deployment stack.
This includes:
- The chosen deployment framework.
- Database schema migration procedures, including Ironic’s table conversion to
UTF8MB4. - Networking backend compatibility, including minimum OVN versions.
- Storage drivers and vendor integrations.
- OpenStack client and API compatibility.
- Service-specific upgrade sequencing.
A SLURP designation is not a universal guarantee of zero-downtime or single-step upgrades.
2. Separate Version Upgrades from Concurrency Changes
Nova’s transition to native threading is particularly important.
Nova’s release notes recommend decoupling the upgrade from the concurrency-mode change, either by testing native threading already in 2025.2 Flamingo, or by explicitly configuring Eventlet mode before the upgrade and switching to threading only after the upgrade succeeds. Operators performing a skip-level upgrade from Epoxy do not pass through Flamingo, so explicitly pinning Eventlet mode before the upgrade is the practical option for them.
Operators should also review the related defaults and limits described above, such as the changed thread-pool and concurrency settings.
Graceful shutdown deserves separate attention. Nova services now support graceful shutdown on SIGTERM, which Nova labels experimental. The compute service creates a second RPC server on a new compute-alt topic, so each compute worker creates an additional RabbitMQ queue and messaging capacity should be reviewed.
Two timeouts control shutdown behavior:
[DEFAULT]/graceful_shutdown_timeoutis the overall time a service waits before exiting forcefully. Its default increases from 60 to 180 seconds for all Nova services.[DEFAULT]/manager_shutdown_timeoutis the time the service manager waits for in-progress tasks, defaulting to 160 seconds, and must be lower than the overall timeout.
Nova advises that external service managers such as systemd or Kubernetes use stop timeouts of at least graceful_shutdown_timeout. For example, TimeoutStopSec should be at least 180 seconds for Nova services.
Source: Nova 2026.1 Release Notes
3. Review API Automation
Automation should be tested against the API microversions and behaviors that clients negotiate.
Particular attention should be given to:
- Asynchronous volume attachment and the absent device name.
- Flavor API response changes and the stricter rejection of unknown query parameters at microversion 2.102 and later.
- Deprecated API endpoints.
- Removed Manila interfaces.
- WSGI deployment entry-point changes in Nova, Neutron, and Cinder.
Applications should not assume that a successful asynchronous request means the underlying operation has completed.
4. Validate Networking Configuration
Gazpacho introduces additional OVN capabilities, but it also contains networking changes that can affect service startup and policy behavior.
Neutron’s 2026.1 release notes describe a startup check on VLAN range configuration: Neutron refuses to start when [ml2_type_vlan] network_vlan_ranges no longer covers a VLAN ID that an existing network segment still holds, for example after a range was narrowed or a physical network was removed. This entry is listed among the stable-branch changes that follow the 28.0.2 tag, so operators should confirm that the Neutron version they deploy includes it.
Operators should ensure that configured VLAN ranges remain consistent with the VLAN IDs already allocated to networks. This is particularly relevant for environments using automated network configuration and infrastructure-as-code workflows.
They should also run Neutron’s upgrade check for RBAC policies and review customized policy files in light of the removal of PROJECT_MANAGER from several default port policies.
Source: Neutron 2026.1 Release Notes
5. Test Storage and Bare Metal Integrations
Storage and bare metal changes should be validated using representative production configurations.
For Cinder, this includes driver-specific capabilities and the behavior of existing volumes when disk geometry settings change.
For Manila, operators should verify compatibility with supported API versions and the capabilities of their selected storage drivers.
For Ironic, the new Redfish Virtual Media transport options require appropriate BMC connectivity and accessible external file shares. The UTF8MB4 database migration should be rehearsed on a copy of production data, and the default behavior of the autodetect deploy interface should be reviewed.
6. Track Stable Point Releases
Several fixes relevant to production operation appear in the 2026.1 stable series after the initial release. For example, Nova’s release notes list a fix for live migration of pre-existing instances with dedicated CPUs failing after upgrading to Gazpacho, and Ironic’s notes include security fixes. Operators should deploy the latest tagged stable point release of each service and confirm that the fixes they depend on are included in the version they run.
7. Establish Post-Upgrade Verification
A production upgrade should include explicit verification criteria rather than relying solely on service availability.
Recommended checks include:
- OpenStack service and API health.
- Instance creation, deletion, resize, and live migration.
- Volume creation, attachment, and detachment.
- Network provisioning, routing, and security-group behavior.
- Image deployment and bare metal provisioning where applicable.
- Identity authentication and authorization.
- Messaging, database, and service health metrics.
- Application-level tests using representative tenant workloads.
These are general operational recommendations, not additional Gazpacho-specific release requirements.
Architectural Assessment
Enterprise Private Cloud and High Availability
Gazpacho offers practical improvements for organizations operating large OpenStack environments.
Parallel live migration connections and Nova’s I/O handling changes may improve compute maintenance workflows and workload behavior in suitable environments.
The native threading transition also creates an opportunity to modernize service operations, although it introduces additional validation requirements during upgrades.
Networking and Infrastructure Integration
Neutron’s OVN BGP enhancements and support for additional external-port routing scenarios are relevant to private cloud platforms integrated with modern routed data center networks.
These capabilities should be evaluated as part of the broader physical and virtual networking architecture, including OVN version requirements, rather than adopted solely because they are available in the release.
Bare Metal and Hybrid Infrastructure
Ironic’s expanded Redfish Virtual Media support and new networking capabilities make Gazpacho particularly relevant to organizations operating mixed virtualized and bare metal infrastructure. The standalone networking service is still experimental, so it is better suited to evaluation than to production reliance for now.
The ability to adopt existing systems into Ironic inventory without performing an operating system deployment also supports more flexible infrastructure lifecycle workflows.
Storage and Multi-Tenancy
Cinder’s driver enhancements and Manila’s QoS capabilities provide additional options for integrating enterprise storage systems and managing shared storage performance.
For multi-tenant environments, the architectural benefit depends on the capabilities and guarantees of the selected backend drivers.
Platform Engineering and Day-2 Operations
Gazpacho reinforces the need to treat OpenStack upgrades as coordinated platform changes.
API evolution, runtime concurrency, messaging topology, database migrations, storage drivers, and networking integrations can all affect operational automation.
Organizations using GitOps, Ansible, or other infrastructure-as-code approaches should incorporate configuration validation, API compatibility testing, and repeatable post-upgrade checks into their release management processes.
Conclusion
OpenStack 2026.1 Gazpacho is an important production release, combining the operational significance of a SLURP milestone with concrete improvements across compute, networking, storage, and bare metal provisioning.
For cloud operators, the most consequential changes are not limited to new capabilities. Nova’s API evolution, the broader transition toward native threading, database migrations such as Ironic’s, and the removal of legacy interfaces require careful attention during upgrade planning.
Organizations considering Gazpacho should begin by validating their supported upgrade path, reviewing service-specific release notes, and testing changes against their actual deployment architecture.
The result should be a more predictable platform lifecycle, with new capabilities introduced through controlled validation rather than assumed compatibility.
