On Aug 8, 2014, at 1:30 PM, Vishvananda Ishaya <[email protected]> wrote:
> Hi Alistair,
>
> Modules can register their own options and there is no need to call
> reload_config_files. The config files are parsed and values stored in case
> the option is later declared. The only time you need to reload files is if
> you add new config files in the new module. See the example code:
>
> from oslo.config import cfg
> with open("foo", "w") as f:
> f.write("[DEFAULT]\nfoo=bar")
>
> cfg.CONF(["--config-file", "foo"])
> try:
> print cfg.CONF.foo
> except cfg.NoSuchOptError:
> print "NO OPT"
> # OUT: 'NO OPT'
>
> cfg.CONF.register_opt(cfg.StrOpt("foo"))
> print cfg.CONF.foo
> cfg.CONF.foo
> # OUT: ‘bar'
>
> One thing to keep in mind is you don’t want to use config values at import
> time, since this tends to be before the config files have been loaded.
>
> Vish
That’s right. The preferred approach is to put the register_opt() in *runtime*
code somewhere before the option will be used. That might be in the constructor
for a class that uses an option, for example, as described in
http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options
Doug
>
> On Aug 8, 2014, at 6:40 AM, Coles, Alistair <[email protected]> wrote:
>
>> I’ve been looking at the implications of applying oslo.config in Swift, and
>> I have a question about the best pattern for registering options.
>>
>> Looking at how keystone uses oslo.config, the pattern seems to be to have
>> all options declared and registered 'up-front' in a single place
>> (keystone/common/config.py) before loading wsgi pipeline/starting the
>> service. Is there another usage pattern where each middleware registers its
>> options independently ‘on-demand’ rather than maintaining them all in a
>> single place?
>>
>> I read about a pattern [1] whereby modules register opts during import, but
>> does that require there to be some point in the lifecycle where all required
>> modules are imported *before* parsing config files? Seems like that would
>> mean parsing the wsgi pipeline to ‘discover’ the middleware modules being
>> used, importing all those modules, then parsing config files, then loading
>> the wsgi pipeline?
>>
>> OR - is it acceptable for each middleware module to register its own options
>> if/when it is imported during wsgi pipeline loading
>> (CONF.register_options()) and then call CONF.reload_config_files() ?
>>
>> Thanks,
>> Alistair
>>
>> [1]
>> http://docs.openstack.org/developer/oslo.config/cfg.html#global-configopts
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> [email protected]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
