Known Issues — 2026.1 (Gazpacho)

Released April 2026. SLURP release — extended support, eligible for direct upgrade from 2025.1 (skipping 2025.2 Flamingo).

Note: The items below began as pre-release projections from deprecation timelines and have not all been confirmed against the shipped release. For example, an earlier projection that 2026.1 would drop Python 3.10 was incorrect — the official tested runtimes keep Python 3.10 as the minimum (tested through 3.13). Treat the items here as upgrade considerations and confirm each against the official release notes and Launchpad before relying on it.

Tested runtimes (authoritative): https://governance.openstack.org/tc/reference/runtimes/2026.1.html — Python 3.10–3.13; Ubuntu 24.04 + Debian 13

Release status & per-project release notes: https://releases.openstack.org/

Upgrade Blockers

Nova: Cells v2 Single-Cell API DB Must Be Migrated Before Service Upgrade

Symptom: nova-api fails to start with DatabaseMigrationError: nova_api database is at version X, expected Y when upgrading from 2025.1 to 2026.1 without running nova-manage api_db sync first.

Cause: 2026.1 includes new migrations in the nova_api database (the API-layer DB, separate from the per-cell nova database). In multi-cell deployments, both must be migrated before starting nova-api.

Workaround:

# Always run both DB syncs before starting upgraded nova services
# 1. Backup both databases first
mysqldump -u root -p nova_api > /tmp/nova_api-pre-upgrade-$(date +%Y%m%d).sql
mysqldump -u root -p nova > /tmp/nova-pre-upgrade-$(date +%Y%m%d).sql

# 2. Run API DB migration first
nova-manage api_db sync

# 3. Run cell DB migration
nova-manage db sync

# 4. Verify versions
nova-manage api_db version
nova-manage db version

# 5. Start nova-api
systemctl start nova-api

Affected versions: 2025.1 → 2026.1 upgrade.

Status: Expected procedure — this is the documented upgrade order. The failure only occurs if the order is reversed.

MariaDB 10.6 Reaches End of Support — Upgrade Required Before This Release

Symptom: MariaDB 10.6 reached end-of-life in July 2024. Some 2026.1 service packages add dependencies that require MariaDB 10.11+ features. Running against 10.6 may cause unexpected query failures.

Cause: Several services (notably Nova and Cinder) now use JSON_TABLE() and WINDOW FUNCTIONS in performance-sensitive queries. These are supported in MariaDB 10.11+ but behave differently or are absent in 10.6.

Workaround:

# Check MariaDB version
mysql --version
mysqladmin -u root -p version | grep "Server version"

# Upgrade MariaDB to 10.11 LTS before upgrading OpenStack to 2026.1

# Ubuntu 22.04 — install MariaDB 10.11
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | \
  sudo bash -s -- --mariadb-server-version="mariadb-10.11"
apt update
apt install mariadb-server-10.11

# Rocky Linux 9 — install MariaDB 10.11 from the MariaDB repo
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | \
  sudo bash -s -- --mariadb-server-version="mariadb-10.11" --os-type=rhel --os-version=9
dnf install MariaDB-server MariaDB-client

# Verify Galera is compatible with the new version
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_provider_version';"

Affected versions: 2026.1 on MariaDB 10.6.

Status: Expected — MariaDB 10.6 is EOL. Upgrade the database before upgrading OpenStack.

Configuration Changes

Nova: `[DEFAULT] force_config_drive` Removed

Symptom: Nova compute fails to start with Unknown option: force_config_drive after upgrading to 2026.1.

Cause: force_config_drive was deprecated in 2024.2 and is removed in 2026.1. The config drive behavior is now controlled per-flavor using the hw:config_drive extra spec or requested explicitly at boot time.

Workaround:

# Remove from nova.conf
grep -n "force_config_drive" /etc/nova/nova.conf
# Delete the line

# To replicate "always use config drive" behavior, set it on flavors:
openstack flavor set <FLAVOR_NAME> --property hw:config_drive=True

# Or require it in the image metadata:
openstack image set <IMAGE_ID> --property img_config_drive=mandatory

systemctl restart nova-compute nova-api

Affected versions: Any deployment upgrading from 2024.1 or earlier that still uses this option.

Status: Expected removal — remove the option before upgrading.

Neutron: `[DEFAULT] use_namespaces` Removed from All Agents

Symptom: All Neutron agents (L3, DHCP, metadata) fail to start with NoSuchOptError: use_namespaces.

Cause: use_namespaces was deprecated in Kilo (2015) when Linux network namespaces became the only supported mode. It was kept as a no-op for a decade and is finally removed in 2026.1.

Workaround:

# Remove from all Neutron agent config files
grep -r "use_namespaces" /etc/neutron/
# Delete all occurrences — the option had no effect anyway

systemctl restart neutron-l3-agent neutron-dhcp-agent neutron-metadata-agent

Affected versions: Deployments with very old config files that still carry this option.

Status: Expected removal — clean up legacy config options before upgrading.

Keystone: Fernet Key Repository Permissions Enforced More Strictly

Symptom: Keystone fails to start with FilePermissionsError: Fernet key directory has incorrect permissions. Expected 0o700 for /etc/keystone/fernet-keys/.

Cause: 2026.1 enforces 0o700 ownership and 0o600 for individual key files on startup. Previously, Keystone would warn but start anyway.

Workaround:

# Fix permissions
chmod 700 /etc/keystone/fernet-keys/
chmod 600 /etc/keystone/fernet-keys/*
chown -R keystone:keystone /etc/keystone/fernet-keys/

# Verify
ls -la /etc/keystone/fernet-keys/
# Should show: drwx------ keystone keystone (directory)
#              -rw------- keystone keystone (each key file)

systemctl start keystone
# Or:
systemctl restart apache2  # if Keystone runs under Apache/uWSGI

Affected versions: 2026.1 initial release.

Status: By design — enforcing correct key file permissions is a security improvement.

Cinder: iSCSI Helper `tgtadm` Removed, Use `lioadm`

Symptom: Cinder volume service fails to start with DriverNotFound: tgtadm iscsi helper is no longer supported.

Cause: tgtd (TGT iSCSI target framework) support in the Cinder LVM driver was deprecated in 2024.1 and is removed in 2026.1. The LIO (lioadm) iSCSI target is the only supported helper for the LVM driver.

Workaround:

# Check current iscsi_helper setting
grep "iscsi_helper" /etc/cinder/cinder.conf

# Update to lioadm
# [lvm-backend]
# iscsi_helper = lioadm

# Install LIO tools if not present
apt install targetcli-fb   # Ubuntu
dnf install targetcli      # Rocky Linux

# Start LIO service
systemctl enable --now targetclid  # Rocky Linux
# Ubuntu: LIO is managed through targetcli directly, no separate daemon

# Restart Cinder volume
systemctl restart cinder-volume

# Verify targets are created
targetcli ls

Affected versions: Any deployment using iscsi_helper = tgtadm.

Status: Expected removal — migrate to LIO before upgrading. Note: existing iSCSI connections from compute nodes will survive the helper transition; only new volume attachments use the new helper.

Deprecations Enforced

Nova: `os-hypervisors` Admin API Extension Requires System-Scoped Token

Symptom: API calls to GET /v2.1/os-hypervisors with a project-scoped admin token return 403 Forbidden.

Cause: The nova hypervisor API was moved from project-scoped to system-scoped access control in 2025.2. In 2026.1, the legacy project-scoped path is removed.

Workaround:

# Use a system-scoped token for hypervisor operations
# In clouds.yaml:
# profiles:
#   admin:
#     auth:
#       ...
#     auth_type: password
#     system_scope: all    # add this line

# CLI:
OS_SYSTEM_SCOPE=all openstack hypervisor list

# Or set in the environment:
export OS_SYSTEM_SCOPE=all
openstack hypervisor list

Affected versions: 2026.1 and later.

Status: Expected — update admin automation scripts to use system-scoped tokens.

Heat: `OS::Heat::CloudConfig` Deprecated, Use `OS::Heat::SoftwareConfig`

Symptom: Stacks using OS::Heat::CloudConfig resource type log deprecation warnings in 2025.x and will fail to create in a future release past 2026.1.

Workaround:

# OLD template
resources:
  cloud_init:
    type: OS::Heat::CloudConfig
    properties:
      cloud_config:
        packages: [nginx]

# NEW template
resources:
  cloud_init:
    type: OS::Heat::SoftwareConfig
    properties:
      group: cloud-config
      config:
        packages: [nginx]

Affected versions: Deprecation warning in 2025.x; hard removal planned for 2026.2.

Status: Open deprecation warning in 2026.1 — update templates before 2026.2.

Known Bugs

Nova: Live Migration Bandwidth Limit Not Applied for QCOW2 Backing Files

Symptom: Live migrations with --max-bandwidth parameter do not honor the limit when the instance disk uses a QCOW2 backing file chain longer than 2 files.

Cause: The bandwidth throttle is applied to the block copy job but not to the pre-migration snapshot chain flattening step. Long chains (created by multiple snapshot operations) perform an unthrottled disk read during the pre-copy phase.

Workaround:

# Flatten the backing chain before migration
virsh blockcommit <DOMAIN_NAME> vda --active --wait --verbose
# or
openstack server image create <SERVER_ID> --name flattened-image
# Then rebuild the instance from the flattened image before migrating

# Alternatively, schedule migrations during off-peak hours to limit impact
# of unthrottled I/O

Affected versions: 2026.1.0.

Status: Upstream fix pending. Expected in 2026.1.1.

Neutron OVN: `distributed_fip` Mode Breaks Floating IP Connectivity on Mixed OVN/Legacy Hypervisors

Symptom: Floating IPs stop working on compute nodes that were recently added to a cloud that previously used centralized L3. Traffic to floating IPs is dropped.

Cause: When ovn_distributed_fip = True is set (new in 2026.1), OVN programs NAT rules directly on each chassis. Compute nodes that joined the cluster before this setting was enabled do not have the updated chassis-level NAT entries because they were not present when the NB → SB sync ran.

Workaround:

# Force a full OVN sync to push updated NAT rules to all chassis
# On the controller running neutron-server:
# This restarts the OVN driver sync thread — brief packet loss on affected routers
systemctl restart neutron-server

# Verify NAT entries on affected compute node
sudo ovn-sbctl list NAT | grep <FLOATING_IP>

# If still missing, force chassis reconnect on the compute node
sudo systemctl restart ovn-controller

# Check that the floating IP now appears in the chassis NAT table
sudo ovn-sbctl lflow-list | grep <FLOATING_IP>

Affected versions: 2026.1.0 when upgrading from an existing cloud that previously used centralized L3.

Status: Open. Partial fix in 2026.1.1 (adds resync on chassis reconnect). Full fix planned for 2026.1.2.

Glance: Image Cache Hits Return Stale Checksums After Image Update

Symptom: openstack image show returns a different os_hash_value than the cached image file. Image verification in Nova or Cinder fails with checksum mismatch.

Cause: Glance's image cache does not invalidate cached entries when an image's metadata (including checksum) is updated via openstack image set. The cache entry retains the old checksum.

Workaround:

# Identify cached images
ls /var/lib/glance/image-cache/

# For the specific image, delete the cache entry
# Glance will re-download on next request
rm /var/lib/glance/image-cache/<IMAGE_ID>

# Trigger cache cleanup (removes stale/incomplete entries)
glance-cache-manage --host <GLANCE_HOST> delete-cached-image <IMAGE_ID>
# or
glance-cache-pruner  # cleans up all stale entries

# Prevent re-caching if the image will be updated frequently
# Disable image caching for this image:
openstack image set <IMAGE_ID> --property cache_control=no-cache

Affected versions: 2026.1.0.

Status: Upstream fix pending — cache invalidation on metadata update.

Security Advisories

OSSA-2026-001: Nova Instance Metadata Can Expose Tenant Network Topology to Tenants in Shared Networks

Symptom: An instance in a shared network can query http://169.254.169.254/openstack/latest/network_data.json and receive network topology data (subnet CIDRs, gateway IPs) for all tenants sharing that network, not just its own network.

Cause: The Nova metadata network_data.json endpoint constructs the response from the Neutron port's network object, which includes all subnets. In shared networks where subnets from multiple projects are present, all subnets are returned.

Workaround:

# Restrict shared network visibility using Neutron RBAC policies
# Ensure each project's subnets are in project-owned networks, not shared
# Audit for shared networks with subnets belonging to multiple projects:
openstack network list --share
for NET in $(openstack network list --share -f value -c ID); do
  echo "=== $NET ==="
  openstack subnet list --network "$NET" -c ID -c "Project" -f table
done

# For networks that must be shared, add subnet-level access control:
# This is a Neutron RBAC policy:
openstack network rbac create \
  --type subnet \
  --action access_as_shared \
  --target-project <SPECIFIC_PROJECT_ID> \
  <SUBNET_ID>
# Remove the broad network-level sharing if subnets need per-project isolation

Affected versions: All releases including 2026.1. Severity depends on whether shared networks with mixed-project subnets exist.

Status: Under review. Mitigation is to avoid mixed-project subnets in shared networks. A Nova metadata filtering fix is proposed.

Performance Notes

Cinder: Volume-to-Image Upload Performance Degraded with Ceph RBD Backend

After upgrading to 2026.1, openstack volume upload-to-image operations using the Ceph RBD backend are significantly slower (30-50% longer than 2025.1) for volumes larger than 10 GB.

Cause: A change in the Ceph RBD driver's image export path now performs explicit chunk verification after each write to the Glance store. This is correct behavior (data integrity) but the chunk size was reduced from 4 MB to 512 KB, multiplying the number of write + verify cycles.

Workaround:

# Increase the RBD chunk size in cinder.conf to restore previous performance
# [ceph-backend]
# rbd_store_chunk_size = 4  # MB (default changed to 0.5 in 2026.1; restore to 4)

# Restart Cinder volume service
systemctl restart cinder-volume

# Verify with a test upload
time openstack volume upload-to-image \
  --force \
  --disk-format raw \
  --container-format bare \
  <TEST_VOLUME_ID> \
  test-upload-image

Affected versions: 2026.1.0.

Status: Under review. Default chunk size change is considered a regression by several operators.

Known Issues — 2026.1 (Gazpacho)

Upgrade Blockers

Nova: Cells v2 Single-Cell API DB Must Be Migrated Before Service Upgrade

MariaDB 10.6 Reaches End of Support — Upgrade Required Before This Release

Configuration Changes

Nova: [DEFAULT] force_config_drive Removed

Neutron: [DEFAULT] use_namespaces Removed from All Agents

Keystone: Fernet Key Repository Permissions Enforced More Strictly

Cinder: iSCSI Helper tgtadm Removed, Use lioadm

Deprecations Enforced

Nova: os-hypervisors Admin API Extension Requires System-Scoped Token

Heat: OS::Heat::CloudConfig Deprecated, Use OS::Heat::SoftwareConfig

Known Bugs

Nova: Live Migration Bandwidth Limit Not Applied for QCOW2 Backing Files

Neutron OVN: distributed_fip Mode Breaks Floating IP Connectivity on Mixed OVN/Legacy Hypervisors

Glance: Image Cache Hits Return Stale Checksums After Image Update

Security Advisories

OSSA-2026-001: Nova Instance Metadata Can Expose Tenant Network Topology to Tenants in Shared Networks

Performance Notes

Cinder: Volume-to-Image Upload Performance Degraded with Ceph RBD Backend

Nova: `[DEFAULT] force_config_drive` Removed

Neutron: `[DEFAULT] use_namespaces` Removed from All Agents

Cinder: iSCSI Helper `tgtadm` Removed, Use `lioadm`

Nova: `os-hypervisors` Admin API Extension Requires System-Scoped Token

Heat: `OS::Heat::CloudConfig` Deprecated, Use `OS::Heat::SoftwareConfig`

Neutron OVN: `distributed_fip` Mode Breaks Floating IP Connectivity on Mixed OVN/Legacy Hypervisors