OpenStack expand/contract migrations: no enforced window before rollback becomes impossible

Answer

There is no enforced or documented time window that automatically makes contract migrations safe to run; the deferral period is purely an operator‑policy decision based on observed stability after expand migrations and new‑code deployment. Online data migrations must be fully completed before a code rollback is considered safe, and each service provides a status command to verify completion. Because downgrade support differs between services and releases, you should audit each service’s Alembic migration tree for tested downgrade() functions before relying on a rollback path.

Likely explanation

The expand/contract pattern separates additive (expand) changes, which can be reversed by simply removing the new columns/tables, from destructive (contract) changes that drop schema objects. Most OpenStack projects do not maintain tested Alembic downgrade() paths for contract steps, so once a contract migration is applied the schema cannot be rolled back without restoring a database backup. Consequently, the project leaves the timing of contract migrations to the operator, who must decide how long to watch the system for regressions after the expand phase and new code are in place.

Confirmed facts

• Expand migrations are additive and safe to roll back by reverting the code; the schema remains readable by the old version.
• Contract migrations drop columns/tables and are effectively irreversible unless a tested downgrade() function exists, which is rare in upstream releases.
• Online data migrations (e.g., nova-manage db online_data_migrations) must finish completely; partially migrated rows may be in a format the old code cannot parse, causing rollback failures even before any contract step runs.
• Each service provides a status command that reports zero pending migrations when online data migrations are done (e.g., nova-manage db online_data_migrations --status).
• Because migration trees and downgrade support vary by service (Nova, Neutron, Cinder, etc.) and by release, operators should inspect the Alembic script directories for each service to confirm whether a downgrade path exists for the contract migrations they intend to apply.

1. Deploy expand migrations and the new service code.
2. Run the service‑specific online data migration to completion.
3. Verify completion with the status command (look for “0 pending”).
4. Observe the system for a policy‑defined stability period (commonly 24‑48 h of normal operation).
5. If the service’s Alembic scripts include tested downgrade() functions for the planned contract migrations, you may shorten the observation window; otherwise, treat the window as the point after which rollback would require a database backup restore.
6. After the observation window, apply contract migrations.

Missing diagnostic detail that could change the recommendation: do the Alembic scripts for the target service and release contain tested downgrade() functions for the contract migrations you plan to run? If yes, the rollback window can be reduced; if no, you must rely on the observed stability period or a backup restore.