keystone.common.sql.upgrades module

keystone.common.sql.upgrades module

class keystone.common.sql.upgrades.Repository(engine, repo_name)[source]

Bases: object

upgrade(version=None, current_schema=None)[source]

Contract the database.

This is run manually by the keystone-manage command once the keystone nodes have been upgraded to the latest release and will remove any old tables/columns that are no longer required.


Expand the database schema ahead of data migration.

This is run manually by the keystone-manage command before the first keystone node is migrated to the latest release.


Return the absolute path to the named repository.

keystone.common.sql.upgrades.get_constraints_names(table, column_name)[source]

Get the initial version of a migrate repository.

Parameters:abs_path – Absolute path to migrate repository.
Returns:initial version number or None, if DB is empty.

Migrate data to match the new schema.

This is run manually by the keystone-manage command once the keystone schema has been expanded for the new release.


Perform and off-line sync of the database.

Migrate the database up to the latest version, doing the equivalent of the cycle of –expand, –migrate and –contract, for when an offline upgrade is being performed.

If a version is specified then only migrate the database up to that version. Downgrading is not supported. If version is specified, then only the main database migration is carried out - and the expand, migration and contract phases will NOT be run.

keystone.common.sql.upgrades.rename_tables_with_constraints(renames, constraints, engine)[source]

Rename tables with foreign key constraints.

Tables are renamed after first removing constraints. The constraints are replaced after the rename is complete.

This works on databases that don’t support renaming tables that have constraints on them (DB2).

renames is a dict, mapping {‘to_table_name’: from_table, …}

keystone.common.sql.upgrades.validate_upgrade_order(repo_name, target_repo_version=None)[source]

Validate the state of the migration repositories.

This is run before allowing the db_sync command to execute. Ensure the upgrade step and version specified by the operator remains consistent with the upgrade process. I.e. expand’s version is greater or equal to migrate’s, migrate’s version is greater or equal to contract’s.

  • repo_name – The name of the repository that the user is trying to upgrade.
  • target_repo_version – The version to upgrade the repo. Otherwise, the version will be upgraded to the latest version available.
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.