admin_port not being properly transposed when launching keystone
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Expired
|
Medium
|
Unassigned |
Bug Description
I noticed this issue while trying to launch devstack. When I got to the point where keystone is supposed to start, it fails to start because of the following traceback:
Traceback (most recent call last):
File "/opt/stack/
options = deploy.
File "/usr/lib/
global_
File "/usr/lib/
global_
File "/usr/lib/
return loader.
File "/usr/lib/
defaults = self.parser.
File "/usr/lib/
defaults[key] = self.get('DEFAULT', key) or val
File "/usr/lib/
return self._interpola
File "/usr/lib/
self, section, option, rawval, vars)
File "/usr/lib/
option, section, rawval, e.args[0])
ConfigParser.
section: [DEFAULT]
option : admin_endpoint
key : admin_port
rawval : http://
If you look at the full debug output, admin_port is clearly identified as 35357:
(keystone-all): 2013-07-16 11:16:02,807 DEBUG cfg log_opt_values admin_endpoint = http://
(keystone-all): 2013-07-16 11:16:02,807 DEBUG cfg log_opt_values admin_port = 35357
but the value of admin_port is not being resolved in the %(admin_port)s variable in the admin endpoint url.
See the full debug output here:
http://
Including the command line used to generate that output.
The only way to work around this, I've found, is to enusre that instead of %(variable)s in the endpoint definition, the values are hard coded:
admin_endpoint = http://
public_endpoint = http://
Doing this in keystone.conf, I am able to successfully start keystone.
Changed in keystone: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in keystone: | |
milestone: | none → havana-3 |
Changed in keystone: | |
assignee: | Dolph Mathews (dolph) → nobody |
status: | In Progress → Triaged |
milestone: | havana-3 → none |
Changed in keystone: | |
status: | Triaged → Incomplete |
Unfortunately, changing the default configuration values won't fix this for existing configurations.
It looks like oslo.config is jumping in to apply the same functionality that we were applying here:
https:/ /github. com/openstack/ keystone/ blob/d803277ee0 6b8f64a520958c6 55e3cabdbacb97b /keystone/ common/ controller. py#L208- L210