[openstack-dev] [all] Lets not assume everyone is using the global `CONF` object (zaqar broken by latest keystoneclient release 1.0)

Doug Hellmann doug at doughellmann.com
Fri Dec 19 14:07:59 UTC 2014

On Dec 19, 2014, at 7:17 AM, Flavio Percoco <flavio at redhat.com> wrote:

> Greetings,
> DISCLAIMER: The following comments are neither finger pointing the
> author of this work nor the keystone team.
> RANT: We should really stop assuming everyone is using a global `CONF`
> object. Moreover, we should really stop using it, especially in
> libraries.
> That said, here's a gentle note for all of us:
> If I understood the flow of changes correctly, keystoneclient recently
> introduced a auth_section[0] option, which needs to be registered in
> order for it to work properly. In keystoneclient, it's been correctly
> added a function[1] to register this option in a conf object.
> keystonemiddleware was then updated to support the above and a call to
> the register function[1] was then added to the `auth_token` module[2].
> The above, unfortunately, broke Zaqar's auth because Zaqar is not
> using the global `CONF` object which means it has to register
> keystonemiddleware's options itself. Since the option was registered
> in the global conf instead of the conf object passed to
> `AuthProtocol`, the new `auth_section` option is not bein registered
> as keystoneclient excepts.
> So, as a gentle reminder to everyone, please, lets not assume all
> projects are using the global `CONF` object and make sure all libraries
> provide a good way to register the required options. I think either
> secretly registering options or exposing a function to let consumers
> do so is fine.
> I hate complaining without helping to solve the problem so, here's[3] a
> workaround to provide a, hopefully, better way to do this. Note that
> this shouldn't be the definitive fix and that we also implemented a
> workaround in zaqar as well.

That change will fix the issue, but a better solution is to have the code in keystoneclient that wants the options handle the registration at runtime. It looks like keystoneclient/auth/conf.py:load_from_conf_options() is at least one place that’s needed, there may be others.


> Cheers,
> Flavio
> [0] https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L20
> [1] https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L49
> [2] https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L356
> [3] https://review.openstack.org/143063
> -- 
> @flaper87
> Flavio Percoco
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list