# Known Issues — 2025.2 (Flamingo)

Released: October 2025. Non-SLURP release. Must upgrade sequentially: 2025.1 → 2025.2 (cannot skip).

---

## Upgrade Blockers

### Cinder: `volume_type_projects` Table Migration Fails on MySQL 8.0 Strict Mode

**Symptom:** `cinder-manage db sync` fails with `Data truncation: Data too long for column 'description' at row 1` when upgrading from 2025.1 to 2025.2.

**Cause:** The 2025.2 migration that adds a `description` column to `volume_type_projects` does not specify a default value. MySQL 8.0 in strict mode (`STRICT_TRANS_TABLES`) rejects the implicit empty default for existing rows.

**Workaround:**
```bash
# Option 1: Temporarily disable strict mode for the migration
mysql -u root -p -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"
cinder-manage db sync
# Re-enable strict mode afterward
mysql -u root -p -e "SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';"

# Option 2: Manually add the column before running the migration
mysql -u root -p cinder -e "
  ALTER TABLE volume_type_projects
  ADD COLUMN description VARCHAR(255) DEFAULT NULL;"
# Then run db sync (migration will detect the column already exists and skip)
cinder-manage db sync
```

**Affected versions:** 2025.1 → 2025.2 upgrade with MySQL 8.0 in strict mode.

**Status:** Fixed in 2025.2.1.

---

### Heat: Stack Resource Pagination Changed — Existing Stacks May Show Truncated Resources

**Symptom:** After upgrading to 2025.2, `openstack stack resource list` returns only 20 resources for stacks with more resources, regardless of `--limit` flag.

**Cause:** Heat changed the default pagination limit for the `resource_list` API from unlimited to 20 in 2025.2 to protect against memory exhaustion on very large stacks. The change was applied globally without a transition period.

**Workaround:**
```bash
# Use explicit --limit to retrieve all resources
openstack stack resource list <STACK_NAME> --limit 500

# Or page through results
openstack stack resource list <STACK_NAME> --limit 100 --marker <LAST_ID>

# For automation scripts, update to use the limit parameter:
openstack stack resource list <STACK_NAME> --limit 1000 -f json | jq 'length'

# Operators who need the old behavior can override the default in heat.conf:
# [DEFAULT]
# max_resources_per_stack = 1000
# The pagination default is in [api] default_limit = 20
# Change it (not recommended for large-scale clouds):
# [api]
# default_limit = 500
```

**Affected versions:** 2025.2.0 and later.

**Status:** Open. The 20-item default is considered correct by the Heat team. Tooling needs to be updated to pass explicit limits.

---

## Configuration Changes

### Neutron: ML2 OVN `ovn_emit_need_to_frag` Enabled by Default

**Symptom:** After upgrading to 2025.2, instances in Geneve-encapsulated networks start receiving ICMP "Fragmentation Needed" messages when sending large packets. Some applications that do not handle PMTUD correctly begin failing.

**Cause:** OVN's `need_to_frag` packet-too-big notifications are now enabled by default (`ovn_emit_need_to_frag = True`) in the OVN ML2 driver to improve MTU handling. Environments where the physical fabric does not allow ICMP type 3 code 4 will see degraded connectivity.

**Workaround:**
```bash
# Check current setting
grep "ovn_emit_need_to_frag" /etc/neutron/plugins/ml2/ml2_conf.ini

# Disable if your fabric blocks ICMP fragmentation-needed messages
# /etc/neutron/plugins/ml2/ml2_conf.ini
# [ovn]
# ovn_emit_need_to_frag = False

# Restart neutron-server
systemctl restart neutron-server

# Alternatively, fix the fabric to allow ICMP type 3:
# On physical switches/firewalls: permit icmp type 3 code 4 (PMTUD)
```

**Affected versions:** 2025.2.0 and later.

**Status:** By design. Disable the option if ICMP type 3 is filtered in your fabric.

---

### Nova: `[compute] reserved_host_disk_mb` Semantics Changed

**Symptom:** After upgrading to 2025.2, placement reports different available disk capacity for compute nodes. Hosts that were previously schedulable for large-disk instances are now rejected.

**Cause:** The meaning of `reserved_host_disk_mb` changed from "reserve this much on the host OS disk" to "reserve this much from the total disk reported to Placement". The effective reservation is now larger for most configurations, reducing schedulable disk.

**Workaround:**
```bash
# Check current value
grep "reserved_host_disk_mb" /etc/nova/nova.conf

# Adjust downward to restore previous schedulable capacity
# The old default was 0, new effective default is equivalent to 5% of disk
# Example: if total disk is 500 GB, old reservation = 0 GB, new = 25 GB
# Set explicitly to the old behavior:
# [compute]
# reserved_host_disk_mb = 0

# Restart nova-compute to update Placement inventories
systemctl restart nova-compute

# Verify updated inventories
openstack resource provider inventory list <RP_UUID>
```

**Affected versions:** 2025.2.0 and later.

**Status:** By design (improved accuracy). Adjust the setting to match desired behavior.

---

### Keystone: `[security_compliance] unique_last_password_count` Now Enforced for Service Accounts

**Symptom:** Service account password rotations (e.g., `openstack user password set nova`) fail with `409 Conflict: Password was used recently`.

**Cause:** In 2025.2, the `unique_last_password_count` security compliance setting now applies to all users including service accounts (previously it only applied to human users in domains with security compliance enabled).

**Workaround:**
```bash
# Check the current setting
grep "unique_last_password_count" /etc/keystone/keystone.conf

# Option 1: Exempt service accounts by placing them in a domain
# with security compliance disabled
openstack domain create --description "Service accounts" services-domain
# Move service users to this domain (requires re-creating them)

# Option 2: Set to 1 to allow any new password
# [security_compliance]
# unique_last_password_count = 1

# Option 3: Reset the password history for a specific user (admin DB operation)
# NOT recommended — use option 1 or 2 instead
```

**Affected versions:** 2025.2.0 and later.

**Status:** By design. Separate service accounts into an unprotected domain if needed.

---

## Deprecations Enforced

### Nova: `[vnc] xvpvncproxy_base_url` and xvpvnc Removed

xvpVNC proxy support (XenServer VNC protocol variant) is removed entirely in 2025.2. The `xvpvncproxy` service and all related config options are no longer available.

```bash
# Remove from nova.conf before upgrading
grep -n "xvp" /etc/nova/nova.conf
# Delete any xvpvncproxy_host, xvpvncproxy_port, xvpvncproxy_base_url lines

# If running the xvpvnc proxy service, stop and disable it
systemctl stop devstack@n-xvnc 2>/dev/null
systemctl disable devstack@n-xvnc 2>/dev/null
```

---

### Cinder: `[lvm] iscsi_ip_address` Deprecated, Use `target_ip_address`

**Symptom:** Cinder volume service logs `DeprecationWarning: [lvm] iscsi_ip_address is deprecated and will be removed in 2026.1. Use target_ip_address instead.`

**Workaround:**
```bash
grep "iscsi_ip_address" /etc/cinder/cinder.conf

# Replace:
# [lvm-backend]
# iscsi_ip_address = 192.168.1.10
# With:
# [lvm-backend]
# target_ip_address = 192.168.1.10

systemctl restart cinder-volume
```

Failure to update before upgrading to 2026.1 will cause the volume service to fail to start.

---

## Known Bugs

### Octavia: Amphora Image Build Fails on Ubuntu 24.04 (Noble) with diskimage-builder

**Symptom:** `octavia-diskimage-create.sh` fails with `Failed to copy iscsi-boot element` on Ubuntu 24.04 build hosts.

**Cause:** The diskimage-builder `iscsi-boot` element references a package (`open-iscsi`) that changed its init system integration in Ubuntu 24.04. The element's `install.d` script fails.

**Workaround:**
```bash
# Build on Ubuntu 22.04 (Jammy) instead, or use the pre-built Octavia image:
# Download the official amphora image for 2025.2
wget https://tarballs.opendev.org/openstack/octavia/test-images/test-only-amphora-x64-haproxy-ubuntu-jammy.qcow2

# Upload to Glance
openstack image create \
  --container-format bare \
  --disk-format qcow2 \
  --file test-only-amphora-x64-haproxy-ubuntu-jammy.qcow2 \
  --tag amphora \
  amphora-x64-haproxy

# Set in octavia.conf
# [controller_worker]
# amp_image_tag = amphora
```

**Affected versions:** 2025.2 with diskimage-builder on Ubuntu 24.04 build hosts.

**Status:** Fixed in diskimage-builder 3.32.1. Upgrade diskimage-builder or use pre-built images.

---

### Nova: Instance Console Unavailable After nova-novncproxy Restart

**Symptom:** After restarting `nova-novncproxy`, active console sessions for running instances return `403 Forbidden` from the console proxy. New console tokens work; old tokens do not.

**Cause:** nova-novncproxy does not persist console token state across restarts. Tokens are stored in memory. When the process restarts, all existing tokens are invalidated but the tokens are not invalidated in the instance metadata — the old tokens are returned to users from cache.

**Workaround:**
```bash
# Instruct users to refresh their console URL
# Programmatically, force a new console URL for affected instances
openstack console url show <SERVER_ID> --novnc
# The new URL contains a fresh token that will work

# For automated systems, clear the console token cache on the instance
# There is no nova CLI for this; users must open the console again in Horizon or re-run `openstack console url show`
```

**Affected versions:** All releases including 2025.2.

**Status:** Open — known limitation of in-memory token storage. A fix using a shared token store (e.g., Redis) is under review for a future release.

---

### Glance: Multi-store Replication Does Not Copy Custom Properties

**Symptom:** When importing images to additional stores (`glance-manage db load_metadefs`), custom image properties (set via `openstack image set --property`) are not carried to the replicated stores.

**Cause:** The image import workflow copies the binary image data but uses only the base schema properties for the new store entry. Extra properties stored in the `image_properties` table are not included in the import metadata.

**Workaround:**
```bash
# After replication, re-apply custom properties to the image in each store
# 1. Get properties from the source image
openstack image show <SOURCE_IMAGE_ID> -f json | \
  jq '.properties | to_entries[] | "--property \(.key)=\(.value)"' -r

# 2. Apply to the replicated image
openstack image set <REPLICATED_IMAGE_ID> \
  --property <KEY1>=<VALUE1> \
  --property <KEY2>=<VALUE2>
```

**Affected versions:** 2025.2.0.

**Status:** Upstream fix pending. Expected in 2025.2.1.

---

## Security Advisories

### OSSA-2025-003: Barbican Secret Container Listing Bypasses ACL Check

**Symptom:** An authenticated user in a project that has been granted `list` access to a secret container can also read secret payloads within that container, even if they do not have `read` access to the individual secrets.

**Cause:** The Barbican container listing API does not enforce per-secret ACLs when expanding secrets within a container response. Only the container-level ACL is checked.

**Workaround:**
```bash
# Restrict container ACLs to minimize exposure
# Avoid granting list access to containers that hold high-sensitivity secrets
# Use separate containers per sensitivity level

# Audit current container ACLs
openstack secret container list --all
# For each container:
openstack secret container get <CONTAINER_HREF> | grep acl

# Remove broad list permissions from sensitive containers
# (Barbican CLI)
barbican acl submit \
  --secret-ref <CONTAINER_HREF> \
  --users ""  # remove all user-level ACL overrides — fall back to project-scoped policy
```

**Affected versions:** 2024.2 through 2025.2.0.

**Status:** Fixed in 2025.2.1 and 2024.2.3. Upgrade Barbican immediately if you use secret containers with mixed-sensitivity secrets.

---

## Performance Notes

### Neutron: OVN Northbound DB Compaction Needed After Large-Scale Port Operations

After performing bulk port operations (create or delete > 10,000 ports in a short period), the OVN NB/SB database can grow significantly. This increases the time for ovn-northd to process changes and ovn-controller to apply them.

```bash
# Check OVN DB size
sudo du -sh /var/lib/ovn/
sudo ovn-nbctl show | wc -l

# Compact the OVN NB and SB databases (brief write stall)
sudo ovsdb-client compact unix:/var/run/ovn/ovnnb_db.sock
sudo ovsdb-client compact unix:/var/run/ovn/ovnsb_db.sock

# Alternatively trigger via ovn-appctl
sudo ovn-appctl -t /var/run/ovn/ovnnb_db.ctl ovsdb-server/compact
sudo ovn-appctl -t /var/run/ovn/ovnsb_db.ctl ovsdb-server/compact

# Schedule periodic compaction (cron, weekly during low-traffic)
# 0 3 * * 0 root /usr/bin/ovsdb-client compact unix:/var/run/ovn/ovnnb_db.sock
```