Open Stack

On Thu, Aug 7, 2014 at 12:54 PM, Kevin L. Mitchell <
kevin.mitchell at rackspace.com> wrote:

> On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote:
> > > In any case, the operative point is that CONF.<attribute> must
> > always be
> > > evaluated inside run-time code, never at module load time.
> >
> > ...unless you call register_opts() safely, which is what I'm
> > proposing.
>
> No, calling register_opts() at a different point only fixes the import
> issue you originally complained about; it does not fix the problem that
> the configuration option is evaluated at the wrong time.  The example
> code you included in your original email evaluates the configuration
> option at module load time, BEFORE the configuration has been loaded,
> which means that the argument default will be the default of the
> configuration option, rather than the configured value of the
> configuration option.  Configuration options must be evaluated at
> RUN-TIME, after configuration is loaded; they must not be evaluated at
> LOAD-TIME, which is what your original code does.
> --
> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
> Rackspace
>

We had this problem in Keystone[1]. There were some config parameters
passed to a function decorator (it was the cache timeout time). You'd
change the value in the config file and it would have no effect... the
default was still used. Luckily the cache decorator also took a function so
it was an easy fix, just pass `lambda: CONF.foo`. The mistaken code was
made possible because the config options were registered at import time.
Keystone now registers its config options at run-time so using CONF.foo at
import-time fails with an error that the option isn't registered.

[1] https://bugs.launchpad.net/keystone/+bug/1265670

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140807/be061f6f/attachment.html>