keystone "--config-file" cli argument is mis-logged

Bug #1782704 reported by donchen
6
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/etc/keystone/keystone.conf
4. The prompt will be printed.

donchen (qishiyexu2)
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
Revision history for this message
Lance Bragstad (lbragstad) wrote :

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/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/589308

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/589308
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=254100128d5b9e2d2cdb2c2cd701666f6c343d61
Submitter: Zuul
Branch: master

commit 254100128d5b9e2d2cdb2c2cd701666f6c343d61
Author: Lance Bragstad <email address hidden>
Date: Mon Aug 6 23:57:00 2018 +0000

    Allow for more robust config checking with keystone-manage

    Keystone was logging a warning saying "no configuration file was
    found" when one was clearly passed to keystone-manage. This was
    due to the fact that keystone-manage was really just checking for
    default configuration file values. This means that users passing
    a specific configuration file location to keystone-manage would
    see a warning that wasn't necessarily true since keystone-manage
    passes sys.argv to oslo.config, which resolves the argument
    properly.

    This change enhances the check to make sure keystone-manage isn't
    dealing with a configuration file passed in from an end-user before
    emitting the warning.

    This change also cleans up some of the interactions between
    keystone.cmd.manage and keystone.cmd.cli to make the variables
    more clear about their purpose.

    Change-Id: I6d58d9c499c447ef1cfd6edd4aeb1176130fb6ad
    Closes-Bug: 1782704

Changed in keystone:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone 14.0.0.0rc1

This issue was fixed in the openstack/keystone 14.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.