38974af24c
Due to MySQL (in some versions) not storing datetime resolution below one second, keystone occasionally ends up with weird behavior such as a New password not being valid. The password created at and expires at columns now store both datetime (for rolling upgrades) and integers. Keystone from Pike and beyond leans on the new created_at_int column and expires_at_int column. Change-Id: I2c219b4b9b353f1e2cce6088849a773196f0e443 Closes-Bug: #1702211
10 lines
458 B
YAML
10 lines
458 B
YAML
---
|
|
upgrade:
|
|
- |
|
|
[`bug 1702211 <https://bugs.launchpad.net/keystone/+bug/1702211>`_]
|
|
Password `created_at` field under some versions/deployments of MySQL would
|
|
lose sub-second precision. This means that it was possible for passwords to
|
|
be returned out-of-order when changed within one second (especially common
|
|
in testing). This change stores password `created_at` and `expires_at` as
|
|
an integer instead of as a DATETIME data-type.
|