Resolve the following RemovedIn20Warning warnings:
The MetaData.bind argument is deprecated and will be removed in
SQLAlchemy 2.0.
The ``bind`` argument for schema methods that invoke SQL against an
engine or connection will be required in SQLAlchemy 2.0.
We are also able to resolve the following RemovedIn20Warning warning,
since the migration away from the bind parameter requires updating these
calls.
The autoload parameter is deprecated and will be removed in version
2.0. Please use the autoload_with parameter, passing an engine or
connection.
Similarly, we can also resolve the following RemovedIn20Warning warning,
since the calls we're updating here are the only ones affected by this
deprecation:
The insert.values parameter will be removed in SQLAlchemy 2.0. Please
refer to the Insert.values() method.
Change-Id: Ic956980a03e1a0e1b6f90c492d8a03a64ea275cc
This change proposes the use of Alembic to manage Glance migrations.
* Introduce new directory ``alembic_migrations`` under
``glance/db/sqlalchemy``. This directory is the home for all glance
migrations henceforth. All the migration scripts reside under
``versions`` directory.
* All the migrations up to Liberty are consolidated into one migration
called ``liberty_initial`` as those migrations are not supported
any more. Mitaka migrations are retained but under a different naming
convention.
* All the glance manage db commands are changed appropriately. They now
use alembic to perform operations such as ``version``, ``upgrade``,
``sync`` and ``version_control``.
* The database versions are not numerical any more. They are the revision
ID of the last migration applied on the database. Since we don't
support migrations before Mitaka, the Liberty version ``42`` will now
appear as ``liberty``. Migration ``43`` and ``44`` in Mitaka appear as
``mitaka01`` and ``mitaka02`` respectively.
* When one performs a ``sync`` or ``upgrade`` command, the database is
first stamped with an equivalent alembic version before upgrading.
* The older migration scripts are retained so that users can correlate
with the new migrations. Also, it is probably safe to retain them until
the alembic migrations become stable. Similarly, the ``migrate_version``
table is not removed yet.
Partially-Implements: blueprint alembic-migrations
Change-Id: Ie8594ff339a13bf190aefa308f54e97ee20ecfa2
Co-Authored-By: Alexander Bashmakov <alexander.bashmakov@intel.com>
Depends-On: I1596499529af249bc48dfe859bbd31e90c48a5e0
Stephen Finucane