Passwords created_at attribute could remain unset during rolling upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Ron De Rose |
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).
Changed in keystone: | |
assignee: | nobody → Henry Nash (henry-nash) |
Changed in keystone: | |
milestone: | none → newton-3 |
Changed in keystone: | |
assignee: | Henry Nash (henry-nash) → Ron De Rose (ronald-de-rose) |
status: | Triaged → In Progress |
Changed in keystone: | |
assignee: | Ron De Rose (ronald-de-rose) → Henry Nash (henry-nash) |
Changed in keystone: | |
assignee: | Henry Nash (henry-nash) → Brant Knudson (blk-u) |
Changed in keystone: | |
assignee: | Brant Knudson (blk-u) → Henry Nash (henry-nash) |
Changed in keystone: | |
assignee: | Ron De Rose (ronald-de-rose) → David Stanek (dstanek) |
Changed in keystone: | |
assignee: | David Stanek (dstanek) → Ron De Rose (ronald-de-rose) |
I added this to the agenda for the Keystone midcycle for Newton: https:/ /etherpad. openstack. org/p/keystone- newton- midcycle