On Aug 8, 2014, at 1:30 PM, Vishvananda Ishaya <vishvana...@gmail.com> 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 <alistair.co...@hp.com> 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
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to