yahoo-eng-team team mailing list archive

[Dolph Mathews <1615014@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Currently, keystone does nothing to prevent an operator from running
each step of the rolling migration process out of order. Theoretically,
most migrations will fail if the table they're looking to drop does not
exist, etc, but that might not always be the case.

The transition to rolling migrations introduces a few expectations
between the migration repositories that we should be able to enforce
rather easily, given that all 3 of the new migration repos should always
contain the same number of migration steps).

1. All legacy migrations need to be run before any --expand migrations
are allow to run.

2. The version number of the --expand repo must be greater than or equal
to the version number of the --migrate repo.

3. The version number of the --migrate repo must be greater than or
equal to the version number of the --contract repo.

I'd expect each command to abort with an error message if there are
outstanding steps from the previous repository that had not been run. As
a bit of a special case, db_sync --expand could (continue to) run the
legacy repository automatically, but only if the legacy repository is
guaranteed to be additive-only, as non-additive migrations should never
be run by --expand (perhaps we should find the version number of the
last non-additive migration and check the current state of the db will
not result in that non-additive migration to be accidentally run.

** Affects: keystone
     Importance: Low
         Status: Triaged


** Tags: upgrades user-experience

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1615014

Title:
  Prevent --expand, --migrate, --contract from being run out of order

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Currently, keystone does nothing to prevent an operator from running
  each step of the rolling migration process out of order.
  Theoretically, most migrations will fail if the table they're looking
  to drop does not exist, etc, but that might not always be the case.

  The transition to rolling migrations introduces a few expectations
  between the migration repositories that we should be able to enforce
  rather easily, given that all 3 of the new migration repos should
  always contain the same number of migration steps).

  1. All legacy migrations need to be run before any --expand migrations
  are allow to run.

  2. The version number of the --expand repo must be greater than or
  equal to the version number of the --migrate repo.

  3. The version number of the --migrate repo must be greater than or
  equal to the version number of the --contract repo.

  I'd expect each command to abort with an error message if there are
  outstanding steps from the previous repository that had not been run.
  As a bit of a special case, db_sync --expand could (continue to) run
  the legacy repository automatically, but only if the legacy repository
  is guaranteed to be additive-only, as non-additive migrations should
  never be run by --expand (perhaps we should find the version number of
  the last non-additive migration and check the current state of the db
  will not result in that non-additive migration to be accidentally run.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615014/+subscriptions