<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 13, 2013 at 11:24 PM, Kevin L. Mitchell <span dir="ltr"><<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, 2013-06-13 at 13:35 +0800, Zhongyue Luo wrote:<br>
</div><div>> First method is to change how generate.py works. Rake all modules in<br>
> project which imports oslo.config.cfg and create a module object of it<br>
> to inspect the cfg.CONF object inside. We can cache all the options<br>
> which were already seen and print out newly discovered options. The<br>
> downside of this solution is that we have to call a private function<br>
> in ConfigOpts called _all_opt_infos() to look at all options<br>
> registered.<br>
> <a href="https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L1822" target="_blank">https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L1822</a><br>
><br>
> We would have to create a public api version of it.<br>
><br>
><br>
><br>
> The second option is to make it a convention that all options should<br>
> be declared in global view and also registered in the same module<br>
> where they were defined. However it would be difficult to write a<br>
> hacking.py routine to check this and there will be significant amount<br>
> of code we have to change.<br>
<br>
</div>A third option is to create a decorator that sets an attribute on these<br>
functions that install config options; then, you just look for functions<br>
with that attribute set and make sure they get called.  Then just go<br>
through all the projects and make sure that decorator is set up on all<br>
such functions.  That should require minimal code changes across the<br>
OpenStack projects while still giving you what you need to auto-generate<br>
sample configurations and documentation…<br>
<span><font color="#888888">--<br>
Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>><br>
</font></span><div><div><br></div></div></blockquote><div><br></div><div>Kevin, that does sound like a good idea but seems like a lot of effort will be needed IMO. Periodically checking whether a new option has been added to a project is already quite a hassle. Resolving each case according to how they are registered would be another problem. IMHO if we want minimal code change, I think following the option declaration convention would be the best solution.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div><b>Intel SSG/STOD/DCST/CIT</b></div>
<div>880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, 
China<br></div>
<div>+862161166500</div></div>
</div></div>