OpenStack Upgrade Pre-Flight Review Prompt

You are a senior OpenStack upgrade engineer who has shepherded production clouds through multiple consecutive releases (Yoga → Zed → Antelope → Bobcat → Caracal → Dalmatian → Epoxy). You know which release notes matter and which are noise.

I will share:
- Current OpenStack release
- Target OpenStack release
- Per-service configs (`nova.conf`, `neutron.conf`, `cinder.conf`, `keystone.conf`, etc.) — sanitized, comments stripped
- Deployment topology (HA-controller count, compute count, Galera vs MySQL, RabbitMQ cluster size, OVS or OVN, Glance backend)
- Current Python version, OS distribution and version

Your job:

1. **List the release jumps** between current and target. If multi-jump, recommend whether to skip-release (where supported) or step through.
2. **For each release jump**, surface from the upstream release notes:
   - **Removed config options** present in the user's config (will fail to start)
   - **Deprecated options** with replacements (warning but should be fixed)
   - **Default value changes** that affect behavior (e.g., `keystone` token format default)
   - **Removed CLI commands** or microversion bumps callers must handle
   - **DB migration types** — online vs offline; expected duration class (seconds / minutes / hours)
   - **API breaking changes** (microversion deprecations, removed extensions)
   - **External dependency bumps** — Python, libvirt, OVN, MySQL/Galera, RabbitMQ minimum versions
3. **Identify ordering constraints**: e.g., Keystone before all others; Neutron before Nova-compute; Placement before Nova-scheduler.
4. **List the data-plane risk**: which steps require VM downtime vs API downtime vs no downtime.
5. **Recommend a rollback path**: which steps are reversible (config), which are not (DB migrations). Explicitly mark the "point of no return."
6. **Pre-flight checks to run before starting**:
   - DB consistency (`nova-manage db sync_check`, `neutron-db-manage check_migration`)
   - Service version skew tolerance
   - Quota table sanity
   - Placement allocation health
   - Orphaned resources (volumes, ports, FIPs)

For each finding: **severity**, **release where introduced**, **affected service/config key**, **action required before upgrade**, **citation hint** (release note section).

---

Current release: [release-name]
Target release: [release-name]
Topology: [DESCRIBE — controller count, compute count, HA storage, OVS/OVN, etc.]
OS / Python: [Ubuntu 22.04 / RHEL 9 / Python 3.10 / etc.]
Service configs (sanitized, comments removed):
```ini
[PASTE nova.conf]
---
[PASTE neutron.conf]
---
[PASTE cinder.conf]
---
[PASTE keystone.conf]
---
[PASTE other relevant configs]
```

Why this prompt works

OpenStack upgrades fail in two ways: forgotten breaking changes (a config option was removed three releases ago and you missed the deprecation warnings) and ordering mistakes (Nova-compute upgraded before Placement). Both are documented upstream but spread across N×6+ services × 5+ release notes.

This prompt forces the model to enumerate the breaking-changes-per-release rather than giving a vague “review release notes” answer.

How to use it

1. Always state both current and target release explicitly. “We’re upgrading from Zed” and “We’re on Zed” are different statements.
2. Strip comments from configs before pasting — they distract the model and the comments are usually old advice anyway.
3. Sanitize: remove passwords, IPs of customer networks, transport URLs with credentials. The model doesn’t need them.
4. Run the prompt 1 release-jump at a time even if you’re skipping. The risks compound but the analysis stays cleaner.

Suggested pre-flight commands

# DB health
sudo nova-manage db sync_check
sudo nova-manage api_db sync_check
sudo neutron-db-manage check_migration
sudo cinder-manage db sync --bump-versions

# Placement integrity
nova-manage placement heal_allocations --dry-run
nova-manage placement audit  # release-dependent

# Service version skew
openstack compute service list
openstack network agent list
openstack volume service list

# Orphans
openstack port list --status DOWN
openstack floating ip list --status DOWN
openstack volume list --status error
openstack server list --all-projects --status ERROR

# Quota drift
nova-manage quota check  # release-dependent
cinder-manage quota sync  # release-dependent

# Config deprecations (live cluster)
sudo grep -i "deprecat" /var/log/{nova,neutron,cinder,keystone,glance}/*.log | tail -100

# Backup
sudo mysqldump --single-transaction --routines --triggers --all-databases | gzip > /backup/pre-upgrade-$(date +%F).sql.gz

Common findings this catches

• [DEFAULT] notification_driver removed in Z+: replaced by [oslo_messaging_notifications] driver. Easy miss; service won’t start.
• policy.json removed — must convert to policy.yaml (or rely on defaults). Old .json is ignored silently.
• scheduler_driver = nova.scheduler.filter_scheduler.FilterScheduler deprecated — short name now required.
• Keystone token format uuid removed long ago — only fernet supported. If old config still says uuid, services fail to validate tokens.
• OVN minimum version bump between releases. Upgrading control plane before OVN bumps causes flow corruption.
• Glance image format changes — qcow2 allowed, vmdk may need feature flag, certain raw images need --container-format bare explicitly.

Rollback-friendly upgrade ordering (high-level)

1. Backup DBs (Nova, Neutron, Cinder, Keystone, Glance, Placement)
2. Upgrade Keystone  (other services need new Keystone client behavior)
3. Upgrade Glance
4. Upgrade Placement
5. Upgrade Nova controllers (api, conductor, scheduler) — NOT computes yet
6. Upgrade Neutron controllers
7. Upgrade Cinder controllers
8. Rolling restart controller services
9. ONLY THEN upgrade Nova computes (one rack at a time)
10. ONLY THEN upgrade Neutron L3/DHCP/OVS agents on networking nodes
11. Run online data migrations (`nova-manage db online_data_migrations`)
12. After 1 week of stability: bump min service versions

Citations: where to verify

The AI may mention specific release notes. Cross-check at:

• https://releases.openstack.org/ — release schedule + EOL
• https://docs.openstack.org///configuration/ — per-service config reference
• https://docs.openstack.org///admin/upgrades.html — upgrade path docs
• Per-release ReleaseNotes.html in each project’s repo

LLMs are prone to inventing option names that “sound right.” Treat every release-note citation as a starting point, not gospel — confirm in upstream docs before changing config.