yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #65804
[Bug 1615014] Re: Prevent --expand, --migrate, --contract from being run out of order
Reviewed: https://review.openstack.org/437441
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6bab551cd8a523332b7c387c36c701cb90fd96bd
Submitter: Jenkins
Branch: master
commit 6bab551cd8a523332b7c387c36c701cb90fd96bd
Author: Richard Avelar <csravelar@xxxxxxxxx>
Date: Thu Feb 23 15:35:21 2017 +0000
Validate rolling upgrade is run in order
This patch addresses a bug that allows rolling upgrades to be run
out of order and without first checking if the previous command
has been run to a higher version before hand.
Change-Id: I55fa4f600d89f3a2fb14868f6886b52fd1ef6c6b
Closes-Bug: 1615014
** Changed in: keystone
Status: In Progress => Fix Released
--
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):
Fix Released
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
References