Public bug reported:
In discussing a fix for bug 1615014 with Richard, we realized that
running:
keystone-manage db_sync --expand
... automatically runs legacy (offline) migrations *specifically* when
upgrading from Mitaka->Newton. Therefore, we don't technically support
zero-downtime, rolling upgrades for Mitaka->Newton, despite having all
the rolling upgrade commands available in Newton.
Therefore, all of the following migration paths are effectively
identical in Mitaka->Newton upgrades, in that they all involve
destructive migrations downtime in the first step:
Migration path A:
keystone-manage db_sync # downtime-incurring operations normally occur
here
Migration path B:
keystone-manage db_sync # downtime-incurring operations normally occur here
keystone-manage db_sync --expand # this becomes a no-op
keystone-manage db_sync --migrate # this becomes a no-op
keystone-manage db_sync --contract # this becomes a no-op
Migration path C:
keystone-manage db_sync --expand # downtime-incurring operations only occur
here in Mitaka->Newton
keystone-manage db_sync --migrate
keystone-manage db_sync --contract # downtime-incurring operations normally
occur here
Migration path A is required for migrations up until Liberty->Mitaka,
and is still supported in Ocata and beyond. Migration path B works, but
there is no reason to recommend this path. Migration path C is
recommended for Newton->Ocata upgrades and beyond.
** Affects: keystone
Importance: Low
Assignee: Dolph Mathews (dolph)
Status: Triaged
** Tags: documentation upgrades
** Changed in: keystone
Status: New => Triaged
--
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/1676925
Title:
db_sync --expand may run downtime-incurring operations
Status in OpenStack Identity (keystone):
Triaged
Bug description:
In discussing a fix for bug 1615014 with Richard, we realized that
running:
keystone-manage db_sync --expand
... automatically runs legacy (offline) migrations *specifically* when
upgrading from Mitaka->Newton. Therefore, we don't technically support
zero-downtime, rolling upgrades for Mitaka->Newton, despite having all
the rolling upgrade commands available in Newton.
Therefore, all of the following migration paths are effectively
identical in Mitaka->Newton upgrades, in that they all involve
destructive migrations downtime in the first step:
Migration path A:
keystone-manage db_sync # downtime-incurring operations normally
occur here
Migration path B:
keystone-manage db_sync # downtime-incurring operations normally occur here
keystone-manage db_sync --expand # this becomes a no-op
keystone-manage db_sync --migrate # this becomes a no-op
keystone-manage db_sync --contract # this becomes a no-op
Migration path C:
keystone-manage db_sync --expand # downtime-incurring operations only occur
here in Mitaka->Newton
keystone-manage db_sync --migrate
keystone-manage db_sync --contract # downtime-incurring operations normally
occur here
Migration path A is required for migrations up until Liberty->Mitaka,
and is still supported in Ocata and beyond. Migration path B works,
but there is no reason to recommend this path. Migration path C is
recommended for Newton->Ocata upgrades and beyond.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1676925/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
