keystone "--config-file" cli argument is mis-logged
Bug #1782704 reported by
donchen
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Lance Bragstad |
Bug Description
Keystone queens version.
Move keystone.conf to a custom location and run `keystone-manage --config-file {my custom location}`, the keystone-manage will not find my conf file and `Config file not found, using default configs.` will be prompted.
Reproduce:
1. git clone keystone queens
2. pip install -r requirements.txt && pip install --prefix=/openstack
3. Run `keystone-manage --config-file /openstack/
4. The prompt will be printed.
affects: | keystone-mapper → keystone |
description: | updated |
Changed in keystone: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in keystone: | |
milestone: | none → rocky-rc1 |
summary: |
- keystone "--config-file" cli argument not work + keystone "--config-file" cli argument is mis-logged |
To post a comment you must log in.
I did some testing with this locally, and the --config-file option appears to be working fine for me.
I do see that keystone-manage appears to mis-communicate the information about the log file though. For example, I moved my keystone.conf from /etc/keystone to /openstack and ran keystone-manage with and without the --config-file parameter. Without the --config-file parameter, keystone-manage uses the default configuration values since it can't find a config file in reasonable locations. It also outputs a message saying it wasn't able to find a configuration file and that it's going to use the default. This is completely reasonable in my opinion.
When I run keystone-manage with --config-file /openstack/ keystone. conf, the utility outputs the same log message, but the output of the command actually makes sense with the values I have in my configuration file. So it appears keystone-manage is using the proper configuration, but logs a message saying that it can't find one.
I think the overall behavior is correct, we just need to find out why the log message is getting output in the second case, since that seems wrong. Here are the steps I took to reproduce this with master [0].
[0] http:// paste.openstack .org/show/ 727435/