keystone-manage bootstrap isn't completely idempotent
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Lance Bragstad | ||
Mitaka |
Fix Released
|
Medium
|
Lance Bragstad | ||
Newton |
Fix Released
|
High
|
Lance Bragstad |
Bug Description
The keystone-manage bootstrap command was designed to be idempotent. Most everything in the bootstrap command is wrapped with a try/except to handle cases where specific entities already exist (i.e. there is already an admin project or an admin user from a previous bootstrap run). This is important because bootstrap handles the creation of administrator-like things in order to "bootstrap" a deployment. If bootstrap wasn't idempotent, the side-effect of running it multiple times would be catastrophic.
During an upgrade scenario, using OpenStack Ansible's rolling upgrade support [0], from stable/newton to master, I noticed a very specific case where bootstrap was not idempotent. Even if the admin user passed to bootstrap already exists, the command will still attempt to update it's password [1], even if the admin password hasn't changed. It does the same thing with the user's enabled property. This somehow creates a revocation event to be stored for that specific user [2]. As a result, all tokens for the user specified in the bootstrap command will be invalid once the upgrade happens, since OpenStack Ansible relies on `keystone-manage bootstrap` during the upgrade.
This only affects the bootstrap user, but it can be considered a service interruption since it is being done during an upgrade. We could look into only updating the user's password, or enabled field, if and only if they have changed. In that case, a revocation event *should* be persisted since the bootstrap command is changing something about the account. In the case where there is no change in password or enabled status, tokens should still be able to be validated across releases.
I have documented the upgrade procedure and process in a separate repository [3]
[0] https:/
[1] https:/
[2] http://
[3] https:/
description: | updated |
Changed in keystone: | |
importance: | Undecided → High |
status: | New → Confirmed |
tags: | added: newton-backport-potential |
tags: | added: mitaka-backport-potential |
Changed in keystone: | |
milestone: | none → ocata-2 |
Adding a little more context for this since jmccrory and I discussed it quite a bit in IRC:
http:// eavesdrop. openstack. org/irclogs/ %23openstack- ansible/ %23openstack- ansible. 2016-12- 05.log. html#t2016- 12-05T22: 19:12