Somewhat related to Bug#1718467.
The ceph-radosgw charm [0] and possibly radosgw itself attempt to use keystone as a PKI. PKI is removed in keystone at Pike. This leads to errors in keystone.log like the following:
(keystoneclient.common.cms): 2018-03-09 04:01:44,271 ERROR Signing error: Unable to load certificate - ensure you have configured PKI with "keystone-manage pki_s
etup"
(keystone.common.wsgi): 2018-03-09 04:01:44,272 ERROR Command 'openssl' returned non-zero exit status 3
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 228, in __call__
result = method(req, **params)
File "/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line 94, in inner
return f(self, request, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/keystone/auth/controllers.py", line 350, in revocation_list
CONF.signing.keyfile)
File "/usr/lib/python2.7/dist-packages/keystoneclient/common/cms.py", line 336, in cms_sign_text
signing_key_file_name, message_digest=message_digest)
File "/usr/lib/python2.7/dist-packages/keystoneclient/common/cms.py", line 384, in cms_sign_data
raise subprocess.CalledProcessError(retcode, 'openssl')
CalledProcessError: Command 'openssl' returned non-zero exit status 3
This does not affect keystone performance but does lead to confusion when reading the logs.
[0] https://github.com/openstack/charm-ceph-radosgw/blob/master/hooks/utils.py#L497
Although this bug is not in the keystone charm, adding it here and marking it invalid, as the keystone charm is the most likely place others will look for this bug.