OpenStack Hibiscus (2026.2): What Changes for Production

OpenStack 2026.2, codenamed Hibiscus, was released on September 30, 2026. Where Gazpacho (2026.1) introduced the first wave of native-threading changes, Hibiscus is largely a release about hardening and cleanup: it adds confidential-computing support in Nova, EVPN and Private VLAN capabilities in Neutron, a large body of security work in Ironic, Glance, Designate, and Cyborg, and a broad set of changed defaults and removed components.

The headline features are AMD SEV-SNP and Intel TDX memory encryption in Nova, Cyborg-managed mediated devices such as vGPUs, BGP EVPN Type-5 route advertisement and Private VLANs in Neutron, a more than 15x memory reduction for ML2/OVS HA router monitoring, Weka and Lustre drivers in Manila, and substantially faster Ironic resource tracking in nova-compute.

For production operators, the features are not the main story. Hibiscus is not a SLURP release, so it can only be reached from Gazpacho. It also changes defaults that affect running clouds: native threading becomes the default for Nova compute and conductor, secure RBAC scope enforcement can no longer be disabled, Ironic defaults to TLS 1.3, NetApp drivers default to HTTPS with certificate verification, and Linux bridge VIF support, several Ironic hardware types, and the standalone Glance API server are removed.

Hibiscus rewards operators who read the upgrade notes service by service. This article summarizes the changes that most affect production planning, and points to the release notes for the details that depend on a specific deployment.

Release at a Glance

Because Hibiscus is not a SLURP release, operators who prefer to upgrade once a year can remain on Gazpacho and target the next SLURP release, 2027.1. Operators already on Gazpacho who want the features below can upgrade directly to Hibiscus.

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

Confidential Computing: AMD SEV-SNP and Intel TDX

What changed

Nova can now launch instances with AMD SEV-SNP (Secure Nested Paging) memory encryption. SEV-SNP adds stronger integrity protection than SEV-ES and enables platform attestation, so guest owners can verify the integrity of their virtual machines through signed attestation reports.

Nova also supports Intel Trust Domain Extensions (TDX) on 5th Gen Xeon Scalable processors or later, providing hardware-enforced memory encryption and CPU state isolation that protects guests from the hypervisor and other privileged software. Attestation is supported through the Quote Generation Service.

Both are requested with the hw:mem_encryption_model flavor extra spec (amd-sev-snp or intel-tdx) or the matching image property. Glance’s metadata definitions were also updated to include amd-sev-snp, and can be refreshed with glance-manage db load_metadefs.

Why it matters

Confidential computing lets organizations run sensitive workloads on shared infrastructure while protecting guest memory even from privileged host software. Attestation gives workload owners a way to verify what they are running on.

Operational impact

These features depend on hardware, firmware, and kernel support that must be validated per host.

Two upgrade behaviors deserve attention:

• nova-compute with the libvirt driver now fails to start if any instance on the host requires AMD SEV-ES memory encryption while the host hardware also has SEV-SNP enabled (detected through the sev_snp parameter of the kvm_amd kernel module). Existing SEV-ES instances should be migrated or deleted before SEV-SNP is enabled in the hardware.
• The deprecated [libvirt] num_memory_encrypted_guests option has been removed, because the maximum number of memory-encrypted guests is now detected automatically through the libvirt API.

Sources:

• Nova 2026.2 Release Notes
• Glance 2026.2 Release Notes

Cyborg-Managed Mediated Devices (vGPU)

What changed

Nova’s libvirt driver can now use mediated devices (such as vGPUs) managed by Cyborg, through a new MDEV accelerator request binding type. Operators can choose to manage the vGPU/mdev lifecycle through Cyborg as an alternative to Nova’s native vGPU support.

Both management paths can coexist. Nova now reports a new OWNER_NOVA trait on the resource providers it manages (root compute node providers, and child providers for pGPUs, memory encryption, and PCI devices), and a scheduler prefilter adds it as a required trait so that Nova-managed and Cyborg-managed devices do not collide.

Why it matters

Operators running accelerated or AI workloads gain a choice in how GPU resources are provided and managed, without having to give up Nova’s existing vGPU support.

Operational impact

The OWNER_NOVA requirement is version-gated: it only activates when all nova-compute services report service version 73 or higher. During a rolling upgrade, Nova logs a warning for each scheduling request in which the trait cannot yet be added. Operators should expect those warnings and verify scheduling behavior once all computes have been upgraded.

Source: Nova 2026.2 Release Notes

Availability Zone Unpinning and Re-pinning

What changed

A new microversion (2.104 is the latest supported in 2026.2) allows a user to remove or restore an instance’s availability zone pin through PUT /servers/{server_id} with pinned_availability_zone. Operators can unpin an instance, migrate it to another availability zone, and optionally re-pin it there, without deleting and recreating it. When re-pinning, only the instance’s current availability zone is accepted.

Operational impact

Automation that manages availability zones can use this to move workloads between zones. Clients must negotiate the new microversion to use it.

Source: Nova 2026.2 Release Notes

Manila virtiofs Shares: Migration and Security

What changed

Cold migration and resize are now supported for instances with virtiofs Manila share attachments. Shares are transparently re-mounted on the destination host and remain available on the source until the resize is confirmed, allowing a clean rollback. The feature requires all nova-compute services to be at service version 74 or later.

Nova compute also reconciles stale Manila share access rules at startup and periodically, controlled by [DEFAULT] stale_share_access_reconcile_interval (default 1800 seconds; 0 or a negative value disables the periodic task).

CephFS shares now use a per-instance, per-host cephx identity instead of a single shared nova identity. Previously, a cephx key recovered from one instance or compute host could grant access to every CephFS share in the cloud.

Operational impact

Grants created before the upgrade keep the shared nova identity until the instance next mounts the share (for example on start, reboot, or migration). The new reconcile task does not revoke legacy shared nova CephFS grants, so draining those remains an operator task.

Source: Nova 2026.2 Release Notes

Native Threading by Default and Graceful Shutdown

What changed

Native threading is now the default concurrency mode for almost all Nova services, including nova-conductor and nova-compute, which were experimental opt-in in Gazpacho. The console proxies (nova-novncproxy, nova-serialproxy, nova-spicehtml5proxy) gained threading support but remain on Eventlet by default, as do the CLI entry points.

A new [DEFAULT] concurrency_backend option accepts auto (default), threading, or eventlet. The OS_NOVA_DISABLE_EVENTLET_PATCHING environment variable takes precedence when both are set. Eventlet mode is deprecated and will be removed no earlier than 2027.2.

Graceful shutdown now uses task tracking. When nova-compute, nova-conductor, or nova-scheduler receives SIGTERM, the service logs its in-progress tasks and waits only until they complete or until manager_shutdown_timeout is reached, instead of always sleeping for the full timeout.

Why it matters

Task tracking shortens routine restarts and gives operators logs of which operations completed and which were cut off, which helps them re-run interrupted work and tune the shutdown timeouts.

Operational impact

Nova recommends separating the version upgrade from the concurrency-mode change: either test native threading for compute and conductor already on Gazpacho (where it is available as an experimental option), or explicitly configure Eventlet mode before the upgrade and switch only after the upgrade has succeeded.

There is a known issue to plan around: a migration-related task tracked on a destination compute service can be left in progress if an error on the source ends the operation without notifying the destination. In that case, shutting down the destination nova-compute may take the full manager_shutdown_timeout. The two documented cases are a live migration rolled back during pre_live_migration, and a cold migration that fails on the source before handing off to finish_resize.

Source: Nova 2026.2 Release Notes

Large Ironic Deployments

What changed

Nova and Ironic coordinated to improve resource tracking in nova-compute services that run the Ironic driver. Nova now avoids repeated per-instance lookups at startup, limits vTPM and pCPU startup validation to the libvirt driver, avoids deep-copying the full Placement provider tree for each Ironic node, and can update per-node resources concurrently through the new [compute] update_resources_max_workers option.

Operational impact

The option defaults to 1, which preserves the previous sequential behavior. Operators of large Ironic deployments can raise it to reduce update_available_resource startup and periodic-task latency, at the cost of additional nova-compute CPU usage and Placement API concurrency.

Sources:

• Nova 2026.2 Release Notes
• Hibiscus Release Highlights

Neutron — Networking

BGP EVPN, Route Leaking, and Private VLANs

What changed

Neutron adds an EVPN service plugin and an OVN agent extension that provision BGP EVPN Type-5 route advertisements, allowing tenant network prefixes to be advertised into the data center fabric through FRR.

The OVN BGP service plugin also gains a leak_routes subnet attribute. When an administrator sets it to True on a Geneve subnet attached to a router with an external gateway, the subnet’s CIDR is advertised as a static route on the BGP main logical router and redistributed to BGP peers through FRR. External hosts can then reach tenant workloads directly, without floating IPs. The attribute is admin-only by default.

A new Private VLAN (PVLAN) service plugin provides an additional port isolation model. Ports can be promiscuous (communicate with any port), isolated (communicate only with promiscuous ports), or part of a community (communicate with community members and promiscuous ports). Ports must belong to a network with the new pvlan property. When PVLAN and security groups both apply to a port, PVLAN takes precedence, and the feature does not support networks or ports with port security disabled.

Why it matters

EVPN Type-5 advertisement and route leaking are relevant to private clouds built on routed data center fabrics. PVLAN provides an isolation option for environments where security-group-based isolation is not the preferred model.

Operational impact

Route leaking has a documented limitation. OVN connects the BGP main logical router to the network’s logical switch, which operates at the network level rather than the subnet level. The IP addresses of all subnets on that network are advertised to the fabric as host routes, but only the leaked subnets are actually routable, so traffic sent to the other addresses is dropped. Subnets that need route leaking should be placed on dedicated networks.

The Neutron API also no longer allows creating VLAN networks when the ovn-bgp service plugin is enabled, because the plugin requires a spine-and-leaf topology that is incompatible with VLAN segregation.

PVLAN requires enabling its service plugin, and the new network and port attributes are exposed in the OpenStack SDK and client.

Sources:

• Neutron 2026.2 Release Notes
• Hibiscus Release Highlights

OVN L3 Scheduling and Routing

What changed

ML2/OVN gains support for the L3 agent scheduler API, including a ha_chassis_priority field that exposes gateway failover ordering within an HA_Chassis_Group (the highest value is the active gateway chassis). The OVN L3 scheduler now uses the HA_Chassis_Group and HA_Chassis tables instead of the deprecated Gateway_Chassis table, and a maintenance task automatically migrates existing references.

Indirect floating IPs are supported for OVN routers through the floating-ip-router-writable extension, which lets callers select the router that hosts a floating IP. An OVN agent extension also supports separate logical switches per VLAN segment, allowing multiple segments per host for routed networks.

Operational impact

For indirect floating IPs, operators must configure routes across every transit hop. Neutron does not validate reachability to the fixed IP subnet and does not protect intermediate router interfaces or static routes from changes that can interrupt connectivity.

The ovn_router_indirect_snat option now defaults to True, so external gateways enable SNAT for nested networks that are indirectly connected through other routers. The option is itself deprecated, because the underlying fix is included in OVN v24.03.4 and later.

Source: Neutron 2026.2 Release Notes

ML2/OVS HA Router Memory Footprint

What changed

The neutron-keepalive-state-change monitor has been rewritten as a POSIX shell script. Neutron reports that the new implementation uses less than 6 MB of RAM per monitor, compared to roughly 100 MB with the previous Python implementation, a reduction of more than 15x.

Why it matters

On clouds running thousands of HA routers on ML2/OVS, per-router monitor memory adds up quickly.

Operational impact

The L3 agent performs a one-time automatic cleanup of legacy Python-based monitor processes at startup, so no manual intervention is required. Two new logging options in l3_agent.ini (router_log_files_in_ha_confs, which defaults to True and keeps the previous behavior, and per_router_log_files) control where the monitor logs.

Source: Neutron 2026.2 Release Notes

Other Neutron Additions

• A security-groups-default-statefulness API extension configures the default stateful attribute of new security groups per project or system-wide, which is useful where stateless security groups are preferred (for example DPDK deployments). By default only administrators can change the setting.
• A DNS forwarder OVS extension enables internal DNS resolution for instances without relying on external connectivity.
• [ovn] ovs_create_tap and the new [OVS_DRIVER] ovs_create_tap now default to True, so os-vif pre-creates the TAP device, which reduces live-migration downtime. Both flags are deprecated and the behavior is expected to stay enabled permanently.
• A per-project quota_router_route quota (default 30) replaces the global max_routes option.
• HAProxy timeouts for the metadata proxy are now configurable in a [metadata_haproxy] group. Operators with slow metadata backends, such as dynamic vendordata, may need to raise timeout_server.

Source: Neutron 2026.2 Release Notes

Cinder — Block Storage

New Drivers and Backend Capabilities

What changed

Cinder adds a new driver for HPE Alletra MP supporting iSCSI, FC, and NVMe/TCP. The Dell PowerFlex driver gains NVMe/TCP support and support for PowerFlex 5.0, which uses an erasure-coded (EC) architecture. Hitachi, HPE/XP, and NEC drivers add Data Reduction Shared (DRS) configuration, and Hitachi adds temporarily immutable snapshots. NetApp’s ASAr2 support now uses an SVM as a pool, and the ONTAP driver adds single-consistency-group replication. The Pure Storage (Everpure) driver implements generic volume group replication actions, and the Quobyte driver adds thin provisioning.

Why it matters

These changes expand the storage platforms and configurations that can be integrated into OpenStack environments.

Operational impact

Backend-specific notes matter here:

• PowerFlex 5.0 (EC generation) is not backward compatible with 4.x (Mirroring generation), and in-place upgrades from 4.x to 5.0 are not supported.
• hitachi_manage_drs_volumes now defaults to True. Cinder’s notes warn that setting it to False may cause failures on volume resize and delete operations after cloning.
• While a Pure Storage replicated group is failed over, cloning a volume, creating a volume from a snapshot, and retyping are rejected, and some group-level operations are unsupported for asynchronously replicated groups.

Driver availability does not imply that every capability is supported identically across backends.

Source: Cinder 2026.2 Release Notes

Secure Defaults and Dependencies

What changed

Several defaults change in ways that can interrupt existing backends:

• [oslo_policy] enforce_scope and enforce_new_defaults now default to True, enabling the RBAC new defaults. Operators who still rely on the old defaults must explicitly set enforce_new_defaults = False before upgrading and plan their migration.
• NetApp ONTAP drivers now default to HTTPS with certificate verification enabled. Backends with self-signed ONTAP certificates must set netapp_ssl_cert_path to a trusted CA bundle, or temporarily set netapp_ssl_cert_verify = false, which is not recommended for production. Backends that set netapp_server_port = 80 while relying on the previous implicit HTTP default must also set netapp_transport_type = http or move to port 443.
• The KIOXIA KumoScale and Lightbits drivers no longer call urllib3.disable_warnings() at import time. Deployments using them will now see InsecureRequestWarning messages that were previously hidden process-wide. The suppress_requests_ssl_warnings option controls them, and the Lightbits driver no longer writes its JWT to debug logs.
• boto3, google-api-python-client, and python-swiftclient are no longer required directly and must be installed when the S3, GCS, or Swift backup drivers are used.
• The IBM FlashSystem drivers have been removed.
• image_conversion_cpu_limit and image_conversion_address_space_limit were renamed image_introspection_cpu_limit and image_introspection_address_space_limit, and the old names are deprecated.

Source: Cinder 2026.2 Release Notes

Data Integrity Fixes

What changed

Cinder’s notes include several fixes for data-integrity problems:

• Restoring an incremental backup chain to a newly created volume with the chunked backup drivers (Swift, S3, Google Cloud Storage, POSIX/NFS) could corrupt data, because the all-zero-chunk optimization was wrongly applied to incrementals.
• The Ceph backup driver could silently truncate a restored sparse volume (such as a LUKS-encrypted one) while reporting success.
• Concurrent creation or deletion of incremental backups sharing a parent could make the dependent-backup counter drift and leave the parent undeletable.
• Rebuilding a boot-from-volume instance on the RBD driver deleted all of the volume’s snapshots from the backend while Cinder still showed them as available.

Operational impact

The dependent-backup counter fix prevents future drift but does not repair values that have already drifted. A backup that wrongly reports dependents continues to do so until its database row is corrected. Operators should audit existing backups, and should treat restores performed with affected versions as candidates for verification.

Source: Cinder 2026.2 Release Notes

Ironic — Bare Metal Provisioning

A Cleanup and Hardening Release

What changed

Ironic describes the cycle as centered on cleanup and stabilization, and reports that it resolved a record number of security vulnerabilities in 2026. Its notes urge operators to read the security sections and the OSSAs and OSSNs issued this year before upgrading.

The SNMP and iLO/iLO5 hardware types have been removed, with Redfish serving as the primary way to manage most hardware, and the iRMC driver has been retired as well. The configuration molds feature has been removed, including the idrac-redfish import/export configuration steps. Python 3.10 support has been dropped.

Why it matters

Removed hardware types are a hard compatibility boundary for operators who still manage servers through those drivers.

Operational impact

Operators using the SNMP, iLO, or iRMC hardware types should migrate to the redfish hardware type before upgrading. Users of the idrac-redfish molds steps need an alternative.

Source: Ironic 2026.2 Release Notes

TLS and Security Defaults

What changed

Ironic adds TLS hardening options across its communication paths, and tightens defaults:

• The default minimum TLS version for the API, JSON-RPC, and agent communication, and for outbound connections to image web servers, is now 1.3 (it was 1.2). Ironic notes that TLS 1.3 is required for post-quantum key exchange, and operators whose infrastructure does not support it can set tls_minimum_version = 1.2.
• Redfish BMC connections have new [redfish] tls_minimum_version and tls_ciphers options, also overridable per node. No default minimum is enforced, to avoid breaking older BMC firmware.
• [agent_containers] defaults no longer disable registry TLS verification, and pull_options and run_options are now list-valued.
• Installation of bootloaders by the Ironic Python Agent is disabled by default (enable_bios_bootloader_install now defaults to False).
• [conductor]/file_url_allowed_paths now defaults to /var/lib/ironic only.
• Kernel parameter options are strictly parsed. Values that fail parsing must be corrected, or conductor.disable_kernel_parameter_parsing can be set to True, which Ironic discourages.
• pxe_template overrides are disabled by default, and the pxe_template driver field is deprecated for removal in the 2027.2 release.
• The IPMI send_raw vendor-passthru step is disabled by default.
• The API rejects oversized or deeply nested JSON bodies through configurable limits, a new [api] enable_ramdisk_endpoints option can disable the /v1/lookup, /v1/heartbeat, and /v1/continue_inspection endpoints on public API instances in split-horizon deployments, and per-step RBAC policies (baremetal:step:execute:<interface>.<step>) and disallow_*_steps options restrict which steps can run.

Operational impact

Operators should verify that image servers, Ironic Python Agent ramdisks, and API clients support TLS 1.3, that deployments needing grub-install from the agent re-enable it explicitly, and that any customized file URLs, kernel parameters, or container-step registries still work with the stricter defaults.

Operators who deployed Gazpacho with the autodetect deploy interface should note a security fix: previously, the interface could silently skip cleaning if automated cleaning started before a deployment had been attempted, leaving the previous tenant’s data on disk. This is fixed in 2026.2.

Source: Ironic 2026.2 Release Notes

API, Runbook, and Firmware Changes

What changed

Ironic’s API advances through microversions 1.112 to 1.115 during the cycle. Runbooks gain a traits field and a description, so eligibility is no longer implied by the runbook’s name (microversion 1.112). The firmware endpoint exposes vendor, model, and serial_number (1.114), and node_history gains state, target_provision_state, and duration_seconds (1.115).

The dedicated firmware interface is now the recommended path for firmware updates, and the equivalent methods on the management interface are deprecated.

Other additions include a container console provider for conductors that run in Docker or Podman containers, a new ironic-manage utility that lists installed hardware types and interfaces, optional polling after Redfish virtual media insertion, retries for BMCs that transiently reject power-on, and a [redfish] read_timeout option.

Operational impact

Upgrades include database changes: an online data migration (migrate_runbook_names_to_traits) seeds the new runbook traits table, and a schema migration adds three nullable columns to firmware_information. The online migration runs as part of ironic-dbsync online_data_migrations and can be executed in batches while the service is running.

Ironic also ships several intermediate releases in a cycle: the Hibiscus release page lists versions 36.0.0 through 39.0.0, and operators should consult the release notes for each.

Source: Ironic 2026.2 Release Notes

Manila — Shared Filesystems

Native Threading by Default

What changed

All Manila services now use Python’s native threading by default. The scheduler, share, and data services no longer require Eventlet monkey patching, and manila-api is unaffected when deployed behind an external WSGI server. Gazpacho offered this only as a technology preview.

Operational impact

Operators who need to revert temporarily can set OS_MANILA_DISABLE_EVENTLET_PATCHING=False in the service environment. The Eventlet backend is deprecated and will be removed in a future release.

Source: Manila 2026.2 Release Notes

New Drivers, Migration API, and Snapshot Access

What changed

Manila adds share drivers for the Weka and Lustre parallel filesystems, aimed at AI/ML and HPC workloads. The Weka driver operates with driver_handles_share_servers=False and maps each Manila project to its own Weka organization, which requires a multi-tenant Weka cluster. The Lustre driver also runs in DHSS=False mode on a pre-provisioned filesystem and requires Lustre 2.16 or later.

Existing drivers gain capabilities: Dell PowerStore adds manage/unmanage for shares and snapshots and QoS (requires PowerStore API 4.1.0.0 or later), Dell PowerScale adds QoS (OneFS 9.5 or later) and asynchronous revert-to-snapshot, and the HPE Alletra MP B10000 driver adds snapshot operations (firmware 10.6.0 or later). Drivers can now perform asynchronous revert-to-snapshot operations.

Share migration APIs graduated from experimental status at API version 2.96, so the X-OpenStack-Manila-API-Experimental header is no longer required from that version on. A new GET endpoint reports migration progress. Mountable snapshots can inherit their parent share’s access rules through the snapshot_inherit_share_access_support extra spec (API 2.99).

Operational impact

Driver prerequisites determine whether the new features are usable on a given backend.

Source: Manila 2026.2 Release Notes

TLS Verification and RBAC Defaults

What changed

Certificate verification is now enabled by default in the Pure Storage FlashBlade, Hitachi HSP, and NetApp ONTAP share drivers. NetApp backends that do not set netapp_transport_type now use HTTPS.

The [oslo_policy] enforce_scope option has been removed, so scope enforcement is always active. The deprecated cephfs_volume_path_prefix option has been removed.

Operational impact

Operators with self-signed or private-CA certificates must supply a CA bundle, install the certificate in the system trust store, or explicitly disable verification (not recommended) before upgrading, or driver initialization will fail. Deployments that had not completed the RBAC transition should review their policy configuration.

Source: Manila 2026.2 Release Notes

Glance — Image Service

What changed

Eventlet has been removed completely, and the standalone glance-api process has been removed. Glance must be deployed under a WSGI server using native threading, with the application glance.wsgi.api:application. Options for the removed HTTP server (bind_host, bind_port, workers, backlog, and others) have been dropped, and [task] task_executor = eventlet is no longer accepted.

Glance now defaults to strict GPT/MBR safety checks on images, ending the transition period in which MBR checks were non-fatal. Images with invalid GPT or protective-MBR data are rejected.

A group of Server-Side Request Forgery fixes covers the web-download and glance-download import methods, OVF processing, the legacy Task API import path, and HTTP(S) image locations. Glance now rejects import and location URIs that target loopback or link-local addresses unless the host is explicitly allowed. Hostnames that resolve to such addresses are also rejected, and private RFC 1918 addresses are not blocked. The web-download plugin now honors image_size_cap, whose default of 1 TiB the notes suggest operators review.

New capabilities include cache clean and prune APIs (Image API 2.18), store preference when downloading images (prefer query parameter), parallel multi-store image import (max_parallel_stores), filesystem store timeouts that return HTTP 503, and credential-free S3 location URLs.

Operational impact

Operators running standalone glance-api must move to a WSGI deployment before upgrading. Operators should audit existing images for invalid GPT/MBR data and review which import methods and hosts they need to allow.

Sources:

• Glance 2026.2 Release Notes
• Hibiscus Release Highlights

Horizon — Dashboard

What changed

Horizon is ready for the new secure RBAC defaults: enforce_scope and enforce_new_defaults are now enabled by default, and domain-scoped tokens are no longer preferred.

The Key Pairs panel now uses the Python/Django implementation by default, at feature parity with the deprecated AngularJS one, and the Python Images table gains search filters, activate/deactivate actions, and a new image metadata form. Instance passwords can now be changed from the dashboard, which requires the QEMU Guest Agent in the guest. A new /auth/switch_name/<project-name> endpoint switches projects by name, and the admin Hypervisors page is faster on deployments that expose vGPU resource providers (with a SHOW_RESOURCE_PROVIDER_SUMMARY option to hide the overview on clouds with many hypervisors).

Horizon officially supports Python 3.14, and Python 3.9 and 3.10 support has been dropped.

Operational impact

Deployments should review their policy configuration before upgrading, and test any customized dashboards or plugins against the new defaults.

Source: Hibiscus Release Highlights

Cyborg, Designate, Freezer, and Watcher

What changed

• Cyborg addressed CVE-2026-40213 and CVE-2026-40214 by scoping requests to projects, requiring service-token validation, and tightening access to hardware management APIs. It adds opt-in persona-based policy defaults for reader, member, manager, service, and admin roles, with the default change planned for 2027.1, and the generic PCI driver returns to fully supported status. python-cyborgclient 3.0.0 removes the deprecated v1 API, including the native cyborg CLI shell, in favor of the openstack accelerator commands.
• Designate fixed OSSA-2026-034 (CVE-2026-71193, CVE-2026-71194), a cross-tenant zone ownership bypass that let a tenant create a subzone, superzone, or duplicate of another tenant’s zone by scheduling it to a different pool, enabling DNS traffic hijacking. It also gained TSIG hardening, post-quantum-cryptography readiness tooling with a check mode that can block service startup on quantum-vulnerable certificate algorithms or outdated TLS versions, a BIND9-based backend for split-horizon DNS, and TLSA record support for DANE.
• Freezer removed its v1 API, finalized its centralized scheduler (which can run with service credentials and multiple instances for high availability), and is now usable through openstack backup commands as an OpenStack Client plugin.
• Watcher services now run on native threading by default, event-driven optimization triggers are protected by access-control policy by default, and two new actions (delete and shelve) were added.

Operational impact

Operators of these services should test startup behavior, policy configuration, and any integrations against the new defaults. Operators using the Freezer v1 API or the Cyborg v1 client must migrate.

Sources:

• Hibiscus Release Highlights
• python-cyborgclient 2026.2 Release Notes

Deprecations, Removals, and Compatibility

Cross-Cutting Changes

• Python 3.10 support is dropped in services including Nova, Glance, and Ironic (the minimum is Python 3.11), and Horizon drops Python 3.9 and 3.10.
• Scope enforcement can no longer be disabled. The deprecated [oslo_policy] enforce_scope option was removed in oslo.policy 6.0.0, and the release notes for Nova, Neutron, Cinder, Manila, Glance, Ironic, and Placement state that scope checks are now always enforced when oslo.policy 6.0.0 is installed. Without that upgrade, scope-enforcement behavior does not change.
• Eventlet is being retired. Glance removed it completely, Manila, Watcher, and almost all Nova services now default to native threading, and Eventlet mode is deprecated in Nova and Manila.

Sources:

• Nova 2026.2 Release Notes
• Neutron 2026.2 Release Notes
• Cinder 2026.2 Release Notes
• Manila 2026.2 Release Notes
• Glance 2026.2 Release Notes
• Ironic 2026.2 Release Notes

Nova Removals

Linux bridge VIF support has been removed from Nova. Instances with binding:vif_type=bridge ports fail to start on upgraded compute nodes, and existing instances using Linux bridge VIFs cannot be managed by upgraded computes until they are migrated. Operators must move to a supported backend such as Open vSwitch or OVN before upgrading. Neutron removed Linux bridge support in 2025.1.

Nova also fails to start nova-compute with file-backed memory enabled unless [DEFAULT] reserved_host_memory_mb is 0.

Source: Nova 2026.2 Release Notes

Neutron Removals and Policy Changes

• [DEFAULT] api_workers has been removed. The number of API workers is determined solely by the uWSGI processes setting, and the default RPC worker count, when rpc_workers is unset, is half the number of CPU threads (capped by available memory). The bind_host and bind_port options, left over from the removed neutron-server service, are also removed.
• The max_routes option has been removed in favor of the quota_router_route quota. neutron-status upgrade check warns if max_routes is still configured with a non-default value.
• The OwnershipValidationHook has been removed, and network access validation for port creation is now handled by the create_port policy. Operators who customized create_port should review their overrides.
• The default delete_port policy now denies deletion of compute:, baremetal:, and manila: ports by regular project users. Admins, service users, and project members or network owners whose request carries a service token (as Nova’s does during server delete) are still allowed.
• Allowed address pairs containing multicast addresses are now rejected (aap-reject-multicast). Pairs created earlier may remain in the database and can interfere with later updates, and the notes suggest clearing multicast pairs during an upgrade.
• The filter-validation extension is enabled by default for ML2 and service plugins, so queries using an invalid filter attribute return HTTP 400.
• New default policy rules cover address group operations and default security group creation, and PROJECT_MANAGER has been removed from several default port policies. Several of these changes are shared with the 2026.1 stable series.
• The fip64 extension support was removed from floating IP pools, which now return only IPv4 subnets.
• An upgrade check detects RBAC policies whose target_project is neither * nor a valid UUID, which are silently ineffective.

Source: Neutron 2026.2 Release Notes

Ironic, Freezer, and Glance Removals

• Ironic removed the SNMP, iLO, and iLO5 hardware types, and retired iRMC.
• Freezer removed its v1 API, which allowed secure RBAC policies and tied backup resources to projects rather than individual users.
• Glance removed the standalone glance-api server.

Sources:

• Ironic 2026.2 Release Notes
• Hibiscus Release Highlights
• Glance 2026.2 Release Notes

Upgrade Considerations for Production

1. Validate the Upgrade Path

Hibiscus is not a SLURP release. Operators must be on Gazpacho (2026.1) before upgrading to Hibiscus, and a rolling upgrade from 2025.2 is not possible. Operators who upgraded Gazpacho as a skip-level upgrade from Epoxy are already in the right place.

Operators who prefer an annual cadence can stay on Gazpacho and plan for the next SLURP release, 2027.1, rather than upgrading to Hibiscus.

As with any release, the deployment framework, storage drivers, networking backend, and vendor integrations must support the upgrade path. A deployment tool’s support for Gazpacho does not imply support for Hibiscus.

2. Separate Version Upgrades from Concurrency Changes

Nova changes the default concurrency mode of nova-conductor and nova-compute to native threading in this release. Nova recommends decoupling this from the version upgrade, either by testing native threading on Gazpacho first (where compute and conductor offered it as experimental options), or by explicitly configuring Eventlet mode before upgrading and switching only after the upgrade has succeeded.

Review the thread-pool and concurrency tuning described in the Nova concurrency guide, and review graceful shutdown behavior and the graceful_shutdown_timeout and manager_shutdown_timeout values. The known issue with migration tasks left in progress on destination computes can extend shutdown times.

Similar considerations apply to Manila, Watcher, and Glance, where native threading is now the default or the only option.

3. Audit Policy and RBAC

Scope enforcement can no longer be disabled once oslo.policy 6.0.0 is installed. Cinder additionally changes the new-defaults setting to True, and Horizon enables both settings by default.

Operators should inventory customized policy files across services, test representative custom roles against the new defaults, and use neutron-status upgrade check and the equivalent upgrade checks for other services before upgrading. Neutron’s changes to create_port, delete_port, and address group policies deserve particular attention.

4. Check TLS and Certificate Assumptions

Several defaults now require valid, trusted certificates and modern TLS:

• Ironic’s minimum TLS version defaults to 1.3 for API, JSON-RPC, agent, and web server connections.
• Cinder and Manila NetApp backends default to HTTPS with certificate verification, and the Manila FlashBlade and Hitachi HSP drivers verify certificates by default.
• Ironic’s [agent_containers] defaults no longer disable registry TLS verification.

Backends that rely on self-signed certificates or on HTTP will fail until their configuration is updated.

5. Remove or Migrate Retired Components

Before upgrading, confirm that no workloads depend on:

• Linux bridge VIFs in Nova.
• SNMP, iLO, iLO5, or iRMC hardware types in Ironic.
• The standalone glance-api server.
• The Freezer v1 API or the Cyborg v1 client.
• The IBM FlashSystem Cinder drivers.

6. Review Database and Online Migrations

Plan for migrations that add indexes or columns. Nova adds two indexes to the migrations table, which can take time on environments with large migration tables. Ironic adds columns to firmware_information and seeds a runbook traits table through an online data migration that runs with ironic-dbsync online_data_migrations. Neutron’s maintenance task migrates Gateway_Chassis references to HA_Chassis_Group configuration automatically.

Rehearse these on a copy of production data to estimate duration.

7. Review API Automation

Automation should be tested against the new microversions and behaviors that clients negotiate:

• Nova API microversion 2.104 and availability zone pinning.
• Ironic API microversions up to 1.115, including runbook changes.
• Manila’s migration APIs no longer requiring the experimental header from API 2.96.
• Neutron’s stricter filter validation, which returns HTTP 400 for invalid filter attributes.

8. Track Stable Point Releases

Several relevant fixes appear in the 2026.2 stable series after the initial release. Neutron’s startup check that refuses to start when network_vlan_ranges no longer covers a VLAN ID held by a network segment is listed among changes following the 29.0.0 tag. Nova’s notes list a fix after the 34.0.0 tag for a regression in 2026.1 in which all requests to the deprecated /os-volumes_boot API failed with HTTP 500. 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.

9. 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 and cold migration.
• Volume creation, attachment, detachment, backup, and restore, including restores from incremental chains.
• Network provisioning, routing, floating IP, and security-group behavior, plus BGP and OVN checks where applicable.
• Image import and upload, with representative formats and sources.
• Bare metal deployment, cleaning, and inspection, including TLS connectivity to BMCs and agents.
• Identity authentication and authorization with representative custom roles.
• Messaging, database, and service health metrics.
• Application-level tests using representative tenant workloads.

These are general operational recommendations, not additional Hibiscus-specific release requirements.

Architectural Assessment

Confidential Computing and Trusted Infrastructure

SEV-SNP and TDX support gives private clouds a path to hardware-backed isolation and attestation for sensitive workloads. The benefit depends on host hardware, firmware, and kernel support, and on how attestation is integrated into tenant workflows. These features are best evaluated on a dedicated set of hosts before being offered broadly.

AI and Accelerated Workloads

Cyborg-managed mediated devices, Weka and Lustre support in Manila, and faster Ironic resource tracking in Nova address common requirements of GPU and HPC platforms. Operators should evaluate each capability against their accelerator hardware, parallel filesystem, and bare metal scale rather than adopting them because they are available.

Networking and Infrastructure Integration

EVPN Type-5 advertisement, route leaking, and Private VLANs expand the options for integrating Neutron with routed data center fabrics. Route leaking in particular has network-level semantics that require careful subnet and network layout, and the ovn-bgp plugin’s incompatibility with VLAN networks is a design constraint to account for early.

Security Posture

Hibiscus continues a pattern of changing defaults toward safer behavior: TLS 1.3 in Ironic, certificate verification in storage drivers, strict image safety checks and SSRF protections in Glance, and mandatory RBAC scope enforcement. These changes improve security posture, and they also convert latent configuration shortcuts into upgrade failures, so they should be treated as migration work rather than incidental changes.

Platform Engineering and Day-2 Operations

Hibiscus reinforces the need to treat OpenStack upgrades as coordinated platform changes. Concurrency models, policy defaults, TLS requirements, database migrations, and removed components all interact with deployment tooling and automation. Organizations using GitOps, Ansible, or other infrastructure-as-code approaches should build configuration validation, policy testing, and repeatable post-upgrade checks into their release management processes.

Conclusion

OpenStack 2026.2 Hibiscus combines notable new capabilities, including confidential computing, vGPU management through Cyborg, EVPN and Private VLAN networking, and new parallel filesystem drivers, with a substantial set of default changes and removals.

For cloud operators, the most consequential changes are the ones that apply to every deployment: the requirement to be on Gazpacho first, mandatory scope enforcement, native threading as the default in Nova compute and conductor, stricter TLS and certificate defaults, and the removal of Linux bridge VIF support, several Ironic hardware types, and the standalone Glance API server.

Organizations considering Hibiscus should begin by confirming their position on the upgrade path, reading the service-specific release notes for the services they run, and testing the changes against their actual deployment architecture. Operators who prefer an annual cadence can wait for the next SLURP release, 2027.1, and plan the same validation against it.

Official Resources

• OpenStack Hibiscus (2026.2) Release Page
• Hibiscus Release Highlights
• Hibiscus Release Schedule
• OpenStack Hibiscus Announcement
• Nova 2026.2 Release Notes
• Neutron 2026.2 Release Notes
• Cinder 2026.2 Release Notes
• Ironic 2026.2 Release Notes
• Manila 2026.2 Release Notes
• Glance 2026.2 Release Notes
• OpenStack Documentation
• OpenStack Releases Index