f174b4fa7c
Switch to alembic for real by integrating it into the 'db sync' command flow. From a user-facing perspective, things should remain pretty much the same as before, with the key difference being that version information (i.e. what's shown by 'keystone-manage db_sync --check' or 'keystone-manage db_version') will now take the form of a hash rather than an integer. There are a few differences for contributors however. The changes are described in the included release note and documentation. Note that there are a couple of important design decisions here that are worth examining: - We drop the idea of the 'data_migration' branch entirely and the 'keystone-manage db_sync --migrate' command is now a no-op. Neutron doesn't do data migrations like we do and yet they manage just fine. Dropping this gets us closer to neutron's behavior, which is a good thing for users. - We haven't re-added the ability to specify a version when doing 'db_sync'. Neutron has this, but the logic needed to get this working is complex and of questionable value. We've managed without the ability to sync to a version since Newton and can continue to do so until someone asks for it (and does the work). - sqlalchemy-migrate is not removed entirely. Instead, upon doing a 'db_sync' we will apply all sqlalchemy-migrate migrations up to the final '079_expand_update_local_id_limit' migration and dummy apply the initial alembic migration, after which we will switch over to alembic. In a future release we can remove the sqlalchemy-migrate migrations and rely entirely on alembic. Until then, keeping this allows fast forward upgrades to continue as a thing. - Related to the above, we always apply *all* sqlalchemy-migrate migrations when calling 'db_sync', even if this command is called with e.g. '--expand' (meaning only apply the expand branch). This is because there is at most one "real" migration to apply, the Xena-era '079_expand_update_local_id_limit' migration, which is an expand-only migration. There is no risk to applying the empty "data_migration" and "contract" parts of this migration, and applying everything in one go results in *much* simpler logic. Future changes will update documentation and add developer tooling for (auto-)generating new migrations, a la 'neutron-db-manage revision'. Change-Id: Ia376cb87f5159a4e79e2cfbab8442b6bcead708f Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
24 lines
1.2 KiB
YAML
24 lines
1.2 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 ``keystone-manage db_version``
|
|
command returns such a version.
|
|
|
|
When the ``keystone-manage db_sync`` command is run without options or
|
|
with the ``--expand`` or ``--contract`` options, all remaining
|
|
sqlalchemy-migrate-based migrations will be automatically applied.
|
|
|
|
Data migrations are now included in the expand phase and the ``--migrate``
|
|
option is now a no-op. It may be removed in a future release.
|
|
|
|
.. __: https://sqlalchemy-migrate.readthedocs.io/en/latest/
|
|
.. __: https://alembic.sqlalchemy.org/en/latest/
|