<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 Jul 27, 2014, at 11:12 PM, Baohua Yang <<a href="mailto:yangbaohua@gmail.com">yangbaohua@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Dear all<div style=""> Thanks for all the responses!</div><div style=""> First, I threw the question actually wanting to hear other voices of the similar requirements of dynamic parsing.</div><div style=""> Glad to get all <span id="93ead71b-dc88-4342-8c2a-40a6e0511192" class="GINGER_SOFTWARE_mark">supports</span> and also questions.</div>
<div style=""> The scenario is that sometime we might define some groups in the config file with changing names. One not appropriated example is that we add a network element with properties as</div><div style=""> [xxx_box]</div>
<div style=""> property1=aaa</div><div style=""> property2=bbb</div><div style=""><br></div><div style=""> In this case, the parser should automatically read in the xxx_box and parses its properties, which would extend the power of the current config lib.</div>
<div style=""> Although we can utilize explicit definitions of <span id="59643500-9c99-40f2-9cc4-2e606a670e16" class="GINGER_SOFTWARE_mark">groups</span> names in our code to ignore uninterested groups in the configuration file, I think it would be more flexible to keep the functionality to read in those undefined groups.</div>
<div style=""> Now I am sure it's impossible to do so with existing <span id="0c7e3205-f41d-4482-8395-05b65d2eb424" class="GINGER_SOFTWARE_mark">olso</span><span id="b1207a7c-45f3-486a-835e-88e81d8adaa2" class="GINGER_SOFTWARE_mark">.</span>config lib.</div>
<div style=""> Thanks for all the feedbacks, and would like to get more comments on whether we should implement this! </div></div></blockquote><div><br></div><div>oslo.config wants options to be registered with well-known names so they are discoverable by tools that produce documentation for deployers. Are the xxx_box names going to be like that? Are all of the options in xxx_box groups the same, or can they vary? How would you describe to a deployer what the group names can be and which options can be included in the section?</div><div><br></div><div>Doug</div><br><blockquote type="cite"><div dir="ltr"><div style=""> </div><div style=""><br></div><div style=""><br></div><div style=""><br></div><div style=""><br>
</div><div style=""><br></div><div style=""><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 1:58 AM, Yuriy Taraday <span dir="ltr"><<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">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><div>I can imagine something like this:</div><div>1. iterate over undefined groups in config;</div><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><br></div><div>So the only thing that oslo.config lacks in its interface here is some way to allow the first step. The rest can be overcomed with some sugar.</div>
<span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</font></span></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><font color="#999999">Best wishes!<br>Baohua<br></font>
</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>