Reviewed: https://review.openstack.org/450863 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e6ef702f22929de831f07e6f56d7b696dfa50b89 Submitter: Jenkins Branch: master
commit e6ef702f22929de831f07e6f56d7b696dfa50b89 Author: Dolph Mathews <dolph.math...@gmail.com> Date: Tue Mar 28 15:40:30 2017 +0000 Doc db_sync --expand incurring downtime in upgrades to Newton The current implementation of db_sync --expand automatically runs any outstanding legacy operations to ensure it's safety. However, that behavior also means that legacy migrations may violate the safety assumptions around --expand. This is only true for Mitaka to Newton upgrades, as there should not be any newer migrations in the legacy repository to be triggered by this behavior. [1] https://github.com/openstack/keystone/blob/0ebd557325ff16c2535dac0eb190792e6d511a79/keystone/common/sql/upgrades.py#L269-L271 Change-Id: Ib175f7fce96011d77eb4783123cb2d265d60aa42 Closes-Bug: 1676925 ** 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/1676925 Title: db_sync --expand may run downtime-incurring operations in upgrades to Newton Status in OpenStack Identity (keystone): Fix Released 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