# 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:** ```bash # 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:** ```bash # 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:** ```bash # 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 --property hw:config_drive=True # Or require it in the image metadata: openstack image set --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:** ```bash # 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:** ```bash # 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:** ```bash # 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:** ```bash # 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:** ```yaml # 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:** ```bash # Flatten the backing chain before migration virsh blockcommit vda --active --wait --verbose # or openstack server image create --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:** ```bash # 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 # 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 ``` **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:** ```bash # 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/ # Trigger cache cleanup (removes stale/incomplete entries) glance-cache-manage --host delete-cached-image # 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 --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:** ```bash # 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 \ # 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:** ```bash # 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-upload-image ``` **Affected versions:** 2026.1.0. **Status:** Under review. Default chunk size change is considered a regression by several operators.