yahoo-eng-team team mailing list archive

[Dolph Mathews <1676925@xxxxxxxxxxxxxxxxxx>]

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