Passwords created_at attribute could remain unset during rolling upgrade

[Henry Nash]

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).

[Dolph Mathews (dolph)]

I added this to the agenda for the Keystone midcycle for Newton: https://etherpad.openstack.org/p/keystone-newton-midcycle

[OpenStack Infra (hudson-openstack)]

Change abandoned by Ron De Rose (<email address hidden>) on branch: master
Review: https://review.openstack.org/355490

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/357789

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/362501

[OpenStack Infra (hudson-openstack)]

Change abandoned by Ron De Rose (<email address hidden>) on branch: master
Review: https://review.openstack.org/362510
Reason: No longer need this patch

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dolph Mathews (<email address hidden>) on branch: master
Review: https://review.openstack.org/357789
Reason: Abandoning in favor of https://review.openstack.org/#/c/362501/

[Steve Martinelli (stevemar)]

this was resolved by https://review.openstack.org/#/c/362501/

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/keystone 10.0.0.0b3 development milestone.