This allows migration to be tuned to a specific deployment. For example,
when we will migrate nodes to hardware types, an option will be used
to specify what to do with missing interfaces.
Change-Id: Ie5045b20b7420fc9b5d864bfb18258a4d8b93334
Related-Bug: #1690185
Now that we have rolling upgrades and the version column was
added and populated in the Pike release, we can add checks to
make sure the versions of objects in the DB are compatible
with this ironic release, before ironic-dbsync's upgrade or
online_data_migrations does its work. These ironic-dbsync
calls are made as part of upgrading to this (Queens) release.
Change-Id: I68758f8a29d483f5c0a7439fa2ea2962b2eb4124
Partial-Bug: #1708243
This adds the new command 'ironic-dbsync online_data_migrations'.
To limit downtime during upgrades, data migrations will be done online
with migration scripts that could be run during normal operation of an
ironic cluster, after the upgrade but before the next one.
Each migration script should ensure that all related DB records are
migrated to the new format. Scripts can detect the format based on
the object version which is stored in the version column.
The online data migration has one script; a function that backfills
the new version column, using versions of objects from the release
prior to this.
This includes code to check the object versions for compatibility with
an ironic release. However, the check is turned off (and will be turned on
in Queens), since we need to boot-strap the new version column before
we can turn the check on. To do this check, we need to keep a list of all
supported versions for every object; release_mapping.RELEASE_MAPPING was
modified so that the object versions is now a list instead of one value.
Change-Id: I1a9fa829951ecf98cae6896d82ba20cf89062394
Closes-Bug: #1585141
Partial-bug: #1526283
Co-Authored-By: Ruby Loo <ruby.loo@intel.com>