yahoo-eng-team team mailing list archive

[Henry Nash <henryn@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Migrate 105 (in Newton) adds the password created_at attribute, and
defaults it to now(). However, this is not a server default, rather it
is a "write to all existing rows" at the time the DB is migrated. The
following rolling upgrade sequence will cause this to remain unset:

1) Imagine a 2 node Mitaka keystone configuration (node A and b), sharing a DB
2) A rolling upgrade is started, and node A is upgrade to Newton, which will migrate the shared DB
3) Before node B can be upgraded, a new user is created with a password via node B. Since this is not running the new Newton code, the code will not know to set the created_at attribute
4) Node B is upgraded to Newton, but this will leave the user record still with created_at as None

The preferred solution would be to have a keystone_manage "rolling
upgrade completion" step, which would check the DB for any rows that did
not have the correct defaults set (i.e. where added during the rolling
migration).

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
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/1596500

Title:
  Passwords created_at attribute could remain unset during rolling
  upgrade

Status in OpenStack Identity (keystone):
  New

Bug description:
  Migrate 105 (in Newton) adds the password created_at attribute, and
  defaults it to now(). However, this is not a server default, rather it
  is a "write to all existing rows" at the time the DB is migrated. The
  following rolling upgrade sequence will cause this to remain unset:

  1) Imagine a 2 node Mitaka keystone configuration (node A and b), sharing a DB
  2) A rolling upgrade is started, and node A is upgrade to Newton, which will migrate the shared DB
  3) Before node B can be upgraded, a new user is created with a password via node B. Since this is not running the new Newton code, the code will not know to set the created_at attribute
  4) Node B is upgraded to Newton, but this will leave the user record still with created_at as None

  The preferred solution would be to have a keystone_manage "rolling
  upgrade completion" step, which would check the DB for any rows that
  did not have the correct defaults set (i.e. where added during the
  rolling migration).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1596500/+subscriptions