<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Aug 8, 2014, at 1:30 PM, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi Alistair,</div><div><br></div>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:<div><br></div><div><div>from oslo.config import cfg</div><div>with open("foo", "w") as f:</div><div> f.write("[DEFAULT]\nfoo=bar")</div><div><br></div><div>cfg.CONF(["--config-file", "foo"])</div><div>try:</div><div> print cfg.CONF.foo</div><div>except cfg.NoSuchOptError:</div><div> print "NO OPT"</div><div> # OUT: 'NO OPT'</div><div><br></div><div>cfg.CONF.register_opt(cfg.StrOpt("foo"))</div><div>print cfg.CONF.foo</div><div>cfg.CONF.foo</div><div># OUT: ‘bar'</div><div><br></div><div>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.</div></div></div></blockquote><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div><br></div><div>Vish</div></div></div></blockquote><div><br></div><div><br></div><div><div>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 <a href="http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options">http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options</a></div><div><br></div><div>Doug</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div></div></blockquote></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div><br></div><div><div>On Aug 8, 2014, at 6:40 AM, Coles, Alistair <<a href="mailto:alistair.coles@hp.com">alistair.coles@hp.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="#0563C1" vlink="#954F72" style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="WordSection1" style="page: WordSection1;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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.<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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?<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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?<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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() ?<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Thanks,<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Alistair<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">[1]<span class="Apple-converted-space"> </span><a href="http://docs.openstack.org/developer/oslo.config/cfg.html#global-configopts" style="color: rgb(149, 79, 114); text-decoration: underline;">http://docs.openstack.org/developer/oslo.config/cfg.html#global-configopts</a><o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" style="color: rgb(149, 79, 114); text-decoration: underline;">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="color: rgb(149, 79, 114); text-decoration: underline;">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br></div></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>