Prevent openstack-upgrade to Rocky if not using Fernet tokens
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Keystone Charm |
Triaged
|
Medium
|
Unassigned |
Bug Description
It is documented in somewhat old release notes [0] that the token provider should be set to Fernet before the upgrade to Openstack Rocky. However, if the upgrade is attempted with the default token-provider for Queens (uuid), the charm attempts to perform the upgrade and fails, ending up in a broken state.
traceback: |
Traceback (most recent call last):
File "/var/lib/
File "/var/lib/
File "/var/lib/
File "/usr/lib/
raise CalledProcessEr
subproces
The traceback above happened because the path for fernet keys doesn't exist - /etc/keystone/
The keystone_error.log also has the following traceback since keystone is trying to import the uuid modules that are no longer available:
mod_wsgi (pid=965232): Exception occurred processing WSGI script '/usr/bin/
Traceback (most recent call last):
File "/usr/bin/
application = initialize_
File "/usr/lib/
name='public', config_
File "/usr/lib/
startup_
File "/usr/lib/
drivers = backends.
File "/usr/lib/
drivers = {d._provides_api: d() for d in managers}
File "/usr/lib/
drivers = {d._provides_api: d() for d in managers}
File "/usr/lib/
super(Manager, self)._
File "/usr/lib/
self.driver = load_driver(
File "/usr/lib/
raise ImportError(msg % {'name': driver_name, 'namespace': namespace})
ImportError: Unable to find 'uuid' driver in 'keystone.
I already created a documentation bug in the charm-guide to highlight the issue in the current documentation [1]. However, given it is a known issue (as documented in the 18.08 charm release notes), the charm should not attempt to perform the upgrade at all and instead short-circuit the process and return an error message.
Ideally, keystone should also check the token-provider configured and handle the mismatch, reporting an error instead of the unhandled exception above.
[0] https:/
[1] https:/
In terms of the keystone charm it probably needs to be handled in the 'openstack-upgrade' action (to fail) if 'action- managed- upgrade' is True.
However, if 'action- managed- upgrade' is False, the the upgrade is triggered with a config-change hook, and so this could need to enter, say, blocked if the upgrade is triggered (openstack- origin= cloud:bionic- rocky) but the token-provider=uuid - however, I think this is problematic.
Then there is the further issue to check that "token-provider" can have an empty default, i.e. pick the default, which on <=queens is uuid, and on >=rocky is ignored. In this scenario, do we switch to fernet automatically during upgrade? Do we do that anyway?
I think my vote for a full fix (in the charm) is on the upgrade to rocky, pre-switch the token to fernet, and then do the upgrade.