yahoo-eng-team team mailing list archive

[OpenStack Infra <1676925@xxxxxxxxxxxxxxxxxx>]

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.mathews@xxxxxxxxx>
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