Bernhard cited usage of os.environ['HOME'] in #1, which I initially glossed over because that's not how auth_token does it today:
cfg.StrOpt('signing_dir', default=os.path.expanduser('~/keystone-signing')),
Source: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L215
However, the fix above, which was for bug 1078947 does not appear to have been backported to folsom (keystone's auth_token).
self.signing_dirname = '%s/keystone-signing' % os.environ['HOME']
Source: https://github.com/openstack/keystone/blob/stable/folsom/keystone/middleware/auth_token.py#L219
Does expanduser() behave differently in suse's case? Should the fix above be backported to folsom?
Bernhard cited usage of os.environ['HOME'] in #1, which I initially glossed over because that's not how auth_token does it today:
cfg.StrOpt( 'signing_ dir', default= os.path. expanduser( '~/keystone- signing' )),
Source: https:/ /github. com/openstack/ python- keystoneclient/ blob/master/ keystoneclient/ middleware/ auth_token. py#L215
However, the fix above, which was for bug 1078947 does not appear to have been backported to folsom (keystone's auth_token).
self. signing_ dirname = '%s/keystone- signing' % os.environ['HOME']
Source: https:/ /github. com/openstack/ keystone/ blob/stable/ folsom/ keystone/ middleware/ auth_token. py#L219
Does expanduser() behave differently in suse's case? Should the fix above be backported to folsom?