<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 2:35 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On Jul 24, 2014, at 5:43 PM, Yuriy Taraday <<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Jul 24, 2014, at 3:08 PM, Yuriy Taraday <<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Jul 24, 2014, at 1:58 PM, Yuriy Taraday <<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Jul 23, 2014, at 11:10 PM, Baohua Yang <<a href="mailto:yangbaohua@gmail.com" target="_blank">yangbaohua@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hi, all<div> The current oslo.cfg module provides an easy way to load name known options/groups from he configuration files.</div><div> I am wondering if there's a possible solution to dynamically load them?</div>
<div><br></div><div> For example, I do not know the group names (section name in the configuration file), but we read the configuration file and detect the definitions inside it.</div><div><br></div><div>#Configuration file:</div>
<div>[group1]</div><div>key1 = value1</div><div>key2 = value2<br clear="all"><div><br></div><div> Then I want to automatically load the group1. key1 and group2. key2, without knowing the name of group1 first.</div>
</div></div></blockquote><div><br></div></div><div>If you don’t know the group name, how would you know where to look in the parsed configuration for the resulting options?</div></div></div></blockquote><div><br></div>
<div>I can imagine something like this:</div><div>1. iterate over undefined groups in config;</div></div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
2. select groups of interest (e.g. by prefix or some regular expression);</div><div>3. register options in them;</div>
<div>4. use those options.</div><div><br></div><div>Registered group can be passed to a plugin/library that would register its options in it.</div></div></div></div></blockquote><div><br></div></div><div>If the options are related to the plugin, could the plugin just register them before it tries to use them?</div>
</div></div></blockquote><div><br></div><div>Plugin would have to register its options under a fixed group. But what if we want a number of plugin instances? </div></div></div></div></blockquote><div><br></div></div><div>
Presumably something would know a name associated with each instance and could pass it to the plugin to use when registering its options.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div>I guess it’s not clear what problem you’re actually trying to solve by proposing this change to the way the config files are parsed. That doesn’t mean your idea is wrong, just that I can’t evaluate it or point out another solution. So what is it that you’re trying to do that has led to this suggestion?</div>
</div></blockquote><div><br></div><div>I don't exactly know what the original author's intention is but I don't generally like the fact that all libraries and plugins wanting to use config have to influence global CONF instance.</div>
</div></div></div></blockquote><div><br></div></div><div>That is a common misconception. The use of a global configuration option is an application developer choice. The config library does not require it. Some of the other modules in the oslo incubator expect a global config object because they started life in applications with that pattern, but as we move them to libraries we are updating the APIs to take a ConfigObj as argument (see oslo.messaging and oslo.db for examples).</div>
</div></div></blockquote></div><div class="gmail_extra"><br></div>What I mean is that instead of passing ConfigObj and a section name in arguments for some plugin/lib it would be cleaner to receive an object that represents one section of config, not the whole config at once.<br clear="all">
</div></div></blockquote><div><br></div></div></div><div>The new ConfigFilter class lets you do something like what you want [1]. The options are visible only in the filtered view created by the plugin, so the application can’t see them. That provides better data separation, and prevents the options used by the plugin or library from becoming part of its API.</div>
<div><br></div><div>Doug</div><div><br></div>[1] <a href="http://docs.openstack.org/developer/oslo.config/cfgfilter.html" target="_blank">http://docs.openstack.org/developer/oslo.config/cfgfilter.html</a></div></div></blockquote>
<div><br></div><div style>Yes, it looks like it. Didn't know about that, thanks!</div><div style>I wonder who should wrap CONF object into ConfigFilter - core or plugin.</div></div><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>