yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #55867
[Bug 1596500] Re: Passwords created_at attribute could remain unset during rolling upgrade
this was resolved by https://review.openstack.org/#/c/362501/
** 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/1596500
Title:
Passwords created_at attribute could remain unset during rolling
upgrade
Status in OpenStack Identity (keystone):
Fix Released
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
References