keystone-manage looks for default_config_files in the wrong place

[Colleen Murphy]

Summary:

The keystone-manage command searches for a default keystone.conf relative to the installed executable [1]. The result is that it will look in <venv name>/../etc/keystone.conf. Failing to find it there, it will search the standard oslo.cfg directories: ~/.keystone/, ~/, /etc/keystone/, /etc/.

I can't find documentation stating keystone.conf should live at <venv name>/../etc/keystone.conf. I can find documentation saying it should live in the etc/ directory of the keystone source directory[2], and I can find documentation saying it should live in one of the oslo.cfg directories[3]. If keystone-manage searched for keystone.conf relative to the python source file keystone/cmd/manage.py rather than the installed binary, the instructions at [2] would work correctly and [3] would still work as a fallback.

Steps to reproduce:

1) Follow the "Developing with Keystone" instructions (http://docs.openstack.org/developer/keystone/developing.html), copying etc/keystone.conf.sample to etc/keystone.conf.

2) Change the database connection string in etc/keystone.conf to sqlite:///keystone2.db

3) Run a keystone-manage db_sync

Expected result:

A sqlite database is created in the current working directory called keystone2.db

Actual result:

A sqlite database is created in the current working directory called keystone.db.

[1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/cmd/manage.py#n23
[2] http://docs.openstack.org/developer/keystone/developing.html#configuring-keystone
[3] http://docs.openstack.org/developer/keystone/configuration.html#configuration-files

[Morgan Fainberg (mdrnstm)]

added to RC, as this seems like a small (but very useful) fix if we can squeeze it into mitaka

[Steve Martinelli (stevemar)]

@Morgan, considering this behaviour would have existed in previous releases, I am less inclined to include it in mitaka.

[Morgan Fainberg (mdrnstm)]

I wouldn't hold up mitaka for it. If we have an RC blocker this might be worth including.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/296110
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=139f892fecf4ce645e3a7a6a7d1087a94f402f89
Submitter: Jenkins
Branch: master

commit 139f892fecf4ce645e3a7a6a7d1087a94f402f89
Author: Colleen Murphy <email address hidden>
Date: Tue Mar 22 16:10:06 2016 -0700

    Fix keystone-manage config file path

    Without this patch, the keystone-manage command looks for a default
    keystone.conf relative to the installed executable. In a developer's
    case this is likely to be relative to <venv name>/bin/keystone-manage.
    If installed via distro packages this will be something like
    /usr/bin/keystone-manage. The keystone developer documentation
    instructs the developer to copy the sample config file into the etc/
    directory of the keystone source directory[1], which is not necessarily
    related to where the keystone-manage executable is installed. This
    patch causes the keystone-manage command to search for
    etc/keystone.conf relative to the python source file,
    keystone/cmd/manage.py, which will always be in the same place relative
    to the keystone repo's etc/ directory. If installed via distro packages
    this will cause keystone-manage to search for the config in something
    like /usr/lib/python2.7/dist-packages, but since it falls back to
    searching the standard oslo.cfg directories, the behavior won't change.

    [1] http://docs.openstack.org/developer/keystone/developing.html#configuring-keystone

    Closes-bug: #1561099

    Change-Id: Icf9caac030e62deb17ce5df3a82737b408591ac0

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/298420

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/298420
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=dd38543bdc2a11b38162fda616fd7933f1539397
Submitter: Jenkins
Branch: stable/mitaka

commit dd38543bdc2a11b38162fda616fd7933f1539397
Author: Colleen Murphy <email address hidden>
Date: Tue Mar 22 16:10:06 2016 -0700

    Fix keystone-manage config file path

    Without this patch, the keystone-manage command looks for a default
    keystone.conf relative to the installed executable. In a developer's
    case this is likely to be relative to <venv name>/bin/keystone-manage.
    If installed via distro packages this will be something like
    /usr/bin/keystone-manage. The keystone developer documentation
    instructs the developer to copy the sample config file into the etc/
    directory of the keystone source directory[1], which is not necessarily
    related to where the keystone-manage executable is installed. This
    patch causes the keystone-manage command to search for
    etc/keystone.conf relative to the python source file,
    keystone/cmd/manage.py, which will always be in the same place relative
    to the keystone repo's etc/ directory. If installed via distro packages
    this will cause keystone-manage to search for the config in something
    like /usr/lib/python2.7/dist-packages, but since it falls back to
    searching the standard oslo.cfg directories, the behavior won't change.

    [1] http://docs.openstack.org/developer/keystone/developing.html#configuring-keystone

    Closes-bug: #1561099

    Change-Id: Icf9caac030e62deb17ce5df3a82737b408591ac0
    (cherry picked from commit 139f892fecf4ce645e3a7a6a7d1087a94f402f89)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/302567
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a78623a456fc0a657a01aa5a887641f0b73d64a8
Submitter: Jenkins
Branch: master

commit 3e5fca06c6b7dd6060721faa39428b133edd10f0
Author: Boris Bobrov <email address hidden>
Date: Tue Apr 5 18:50:48 2016 +0300

    Update federated user display name with shadow_users_api

    When a user comes to the cloud for the first time, a shadow user is
    created. When the user authenticates again, this shadow user is
    fetched and returned. Before it is returned, its display name should
    be updated. But the call to update the display name fails because
    neither identity manager nor identity drivers have the required
    method. However, the required method exists in shadow_users_api.

    The issue was hidden because method shadow_federated_user was
    cached and while the cache lived, the user could authenticate.

    Use the method of shadow_user_api instead of identity_api to update
    federated user display name.

    Change-Id: I58e65bdf3a953f3ded485003939b81f908738e1e
    Closes-Bug: 1566282
    (cherry picked from commit 7ad4f8728cce354617b5facefe5076d65af311c6)

commit dba04cdd232ab72704df58cff791d52c1c99bc90
Author: Morgan Fainberg <email address hidden>
Date: Mon Mar 28 10:50:12 2016 -0700

    Correct `role_name` constraint dropping

    The `role_name` constraint was not properly dropped in some cases
    because the unique constraint was not consistently named. In all
    cases we must search for the constraint expected, not assume the
    name of the constraint will be consistent (especially from older
    installs that have been moved forward in releases).

    This change fixes migration 88, updates 96 (for backport to
    stable/mitaka) This is being overly cautious, but specifically
    is to handle the case where someone performed the upgrade and
    manually fixed the migration resulting in duplicated constraints
    in the role_table. Note that migration 100 was not backported since
    it was a placeholder migration.

    Conflicts:
        keystone/tests/unit/test_sql_upgrade.py

    Co-Authored-By: "Matthew Thode" <email address hidden>
    Change-Id: Ie0dc3d2449bace57d3e9323b281a2abd2ad0c983
    closes-bug: #1562934
    (cherry picked from commit 276e57e2083dcad8cbabf9aa9b3bd06c6079c415)

commit cf1fd9dad7d89d50a10ab204aa487663ea258988
Author: OpenStack Proposal Bot <email address hidden>
Date: Wed Mar 30 06:16:27 2016 +0000

    Imported Translations from Zanata

    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure

    Change-Id: Iff9556deb5ebb465c7124c120e7806774c517472

commit c4b08ed2522ee771331d53f153bda5098c9fb9f4
Author: OpenStack Proposal Bot <email address hidden>
Date: Tue Mar 29 06:52:52 2016 +0000

    Imported Translations from Zanata

    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure

    Change-Id: I1e81320c932549e38bade5ef8d885ef426990f40

commit dd38543bdc2a11...

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/keystone 10.0.0.0b1 development milestone.