64621053c2
This is significantly easier than Cinder, Nova etc. as Heat hasn't had any database migrations in multiple cycles, meaning we don't need to worry about having to apply any older sqlalchemy-migrate migrations before switching to alembic. Instead, we simply need to determine we're upgrading a deployment that was previously using sqlalchemy-migrate, upgrading a deployment that has already migrated to alembic, or deploying a new deployment, adjusting accordingly. Signed-off-by: Stephen Finucane <stephenfin@redhat.com> Change-Id: I808af9cb21ba21808209b1daddac7426f4cad310
23 lines
1.1 KiB
YAML
23 lines
1.1 KiB
YAML
---
|
|
upgrade:
|
|
- |
|
|
The database migration engine has changed from `sqlalchemy-migrate`__ to
|
|
`alembic`__. For most deployments, this should have minimal to no impact
|
|
and the switch should be mostly transparent. The main user-facing impact is
|
|
the change in schema versioning. While sqlalchemy-migrate used a linear,
|
|
integer-based versioning scheme, which required placeholder migrations to
|
|
allow for potential migration backports, alembic uses a distributed version
|
|
control-like schema where a migration's ancestor is encoded in the file and
|
|
branches are possible. The alembic migration files therefore use a
|
|
arbitrary UUID-like naming scheme and the ``heat-manage db_sync`` command
|
|
now expects such an version when manually specifying the version that should
|
|
be applied. For example::
|
|
|
|
$ heat-manage db_sync c6214ca60943
|
|
|
|
Attempting to specify an sqlalchemy-migrate-based version will result in an
|
|
error.
|
|
|
|
.. __: https://sqlalchemy-migrate.readthedocs.io/en/latest/
|
|
.. __: https://alembic.sqlalchemy.org/en/latest/
|