The oslo_config_config conf option cannot be used because it gets clobbered

[Chris Dent]

keystonemiddleware.auth_token provides mechanisms for not using paste to configure the middleware. If 'oslo_config_project' is set in the conf passed to the middleware, then three different things could happen:

* a ConfigOpts is created and populated by the default configuration for the named project
* if 'oslo_config_file' is set, then that file is used to load the config
* if 'oslo_config_config' is present and is a ConfigOpts, its config is used

This last one does not work because the line of code immediately following clobbers it by resetting the config to new values.

The fix is to have a bit of conditional, coming soon in a patch near you.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/274396
Committed: https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=dc22e9fd30ea678edaf0a3237ed10c49128e87d9
Submitter: Jenkins
Branch: master

commit dc22e9fd30ea678edaf0a3237ed10c49128e87d9
Author: Chris Dent <email address hidden>
Date: Sun Jan 31 02:05:40 2016 +0000

    Remove clobbering of passed oslo_config_config

    Calling a ConfigOpts instance with new args will implicitly reset
    the config values in the instance. This means that in the previous
    revision of the code, any assignment of oslo_config_config to
    self._local_oslo_config would be instantly clobbered by calling
    self._local_oslo_config() to read from default_config_files.

    Now, if oslo_config_config is set to a non-None value it will be
    left unmolested. This is useful because oslo_config_config turns out
    to be the ideal way to pass config to AuthProtocol when the caller
    already has access to the project config object and neither global
    conf nor paste is being used.

    Change-Id: I0beb809bc5ace609561f10dc52800a8a6e03f7e6
    Closes-Bug: #1540022

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/keystonemiddleware 4.3.0 release.