<div dir="ltr">Renat,<div><br></div><div>I want to avoid having to explicitly import the mistral.config module in order to have configuration loaded properly. The problem with the way mistral.config is coded is that we have to use importutils otherwise we get pep8 error if we simply insert "from mistral import config". An example at <a href="https://github.com/stackforge/mistral/blob/master/mistral/engine/__init__.py#L29">https://github.com/stackforge/mistral/blob/master/mistral/engine/__init__.py#L29</a>. This seems to be a chore when it comes down to writing tests where the mistral.config is not necessary loaded (whereas the launch script registers the configuration because the parse_args function in mistral.config is called and the problem isn't as apparent). So we see the importutils.import_module('mistral.config') scattered in multiple tests.<br>
</div><div><br></div><div>My initial patchset has all the configurations under mistral.config but I have them separated into different methods. The tools/config/generate_sample.sh expects the options to be at top level in the module. I also looked at a few other OpenStack projects for reference (i.e. nova, ceilometer, oslo.messaging) and then in the latest patchset moved them closer to the modules where they are needed thinking this may be more consistent with other projects. </div>
<div><br></div><div>I can certainly revisit this and explore an alternate way to keep these config together and avoid the importutils problem. This may be minor but I want to take care of this clean up before we hit the ground running with juno related bps.</div>
<div><br>Winson</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 22, 2014 at 8:29 AM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.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">I tend to disagree with the whole idea. Not sure 100% though yet. Could you please explain the point of scattering configuration all over the code? In my opinion, we’re mixing different application concerns. With the current approach I always know where to look at in order to find all my configuration option definitions (types, descriptions etc.) but with this refactoring it seems to be a tricky task.<div>
<br></div><div>Thoughts? What benefits of doing that?<span class="HOEnZb"><font color="#888888"><br></font></span><div><span class="HOEnZb"><font color="#888888"><br><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br>
</div></font></span><div><div class="h5">
<br><div><div>On 16 May 2014, at 21:32, Dmitri Zimine <<a href="mailto:dz@stackstorm.com" target="_blank">dz@stackstorm.com</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word"><div><div>+1 for breaking down the configuration by modules. </div>
<div><br></div><div>Not sure about names for configuration group. Do you mean just using the same group name? or more? </div><div><br></div><div>IMO groups are project specific; it doesn’t always make sense to use the same group name in the context of different projects. Our requirement is 1) auto-generate mistral.conf.example from the config.py and 2) sections make sense in the product context.</div>
<div><br></div><div>For example: how do we deal with rpc_backend and transport_url for oslo messaging? Should we do something like CONF.import(_transport_opts, “oslo.messaging.transport”, “transport”)? And use it by passing the group, not entire contfig, like:</div>
<div><br></div><div><span style="white-space:pre-wrap"> </span>transport = messaging.get_transport(cfg.messaging.CONF)</div><div>instead of</div><div><span style="white-space:pre-wrap"> </span>transport = messaging.get_transport(cfg.CONF)</div>
<div><br></div><div>DZ> </div><div><br></div><div><br></div><div>On May 16, 2014, at 12:46 PM, W Chan <<a href="mailto:m4d.coder@gmail.com" target="_blank">m4d.coder@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">Regarding config opts for keystone, the keystoneclient middleware already registers the opts at <a href="https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325" target="_blank">https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325</a> under a keystone_authtoken group in the config file. Currently, Mistral registers the opts again at <a href="https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108" target="_blank">https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108</a> under a different configuration group. Should we remove the duplicate from Mistral and refactor the reference to keystone configurations to the keystone_authtoken group? This seems more consistent.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 1:13 PM, W Chan <span dir="ltr"><<a href="mailto:m4d.coder@gmail.com" target="_blank">m4d.coder@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">Currently, the various configurations are registered in ./mistral/config.py. The configurations are registered when mistral.config is referenced. Given the way the code is written, PEP8 throws referenced but not used error if mistral.config is referenced but not called in the module. In various use cases, this is avoided by using importutils to import mistral.config (i.e. <a href="https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/engine/test_transport.py#L34" target="_blank">https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/engine/test_transport.py#L34</a>). I want to break down registration code in ./mistral/config.py into separate functions for api, engine, db, etc and move the registration closer to the module where the configuration is needed. Any objections?</div>
</blockquote></div><br></div>
_______________________________________________<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>
</blockquote></div><br></div>_______________________________________________<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>
</blockquote></div><br></div></div></div></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></div>