<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;"><div apple-content-edited="true"><div><br></div></div><div><div>On 12 Mar 2014, at 06:37, W Chan <<a href="mailto:m4d.coder@gmail.com">m4d.coder@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Here're the proposed changes.</div><div class="gmail_extra">1) Rewrite the launch script to be more generic which contains option to launch all components (i.e. API, engine, executor) on the same process but over separate threads or launch each individually.</div></div></blockquote><div><br></div><div>You mentioned test_executor.py so I think it would make sense first to refactor the code in there related with acquiring transport and launching executor. My suggestions are:</div><div><ul class="MailOutline"><li>In test base class (mistral.tests.base.BaseTest) create the new method <b>start_local_executor()</b> that would deal with getting a fake driver inside and all that stuff. This would be enough for tests where we need to run engine and check something. start_local_executor() can be just a part of setUp() method for such tests.</li><li>As for the launch script I have the following thoughts:</li><ul><li>Long-term launch scripts should be different for all API, engine and executor. Now API and engine start within the same process but it’s just a temporary solution.</li><li>Launch script for engine (which is the same as API’s for now) should have an option <b>--use-local-executor</b> to be able to run an executor along with engine itself within the same process.</li></ul></ul></div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra">2) Move transport to a global variables, similar to global _engine and then shared by the different component.</div></div></blockquote><div><br></div><div>Not sure why we need it. Can you please explain more detailed here? The better way would be to initialize engine and executor with transport when we create them. If our current structure doesn’t allow this easily we should discuss it and change it.</div><div><br></div><div>In mistral.engine.engine.py we now have:</div><div><br></div><div> def load_engine():</div><div> global _engine</div><div> module_name = cfg.CONF.engine.engine</div><div> module = importutils.import_module(module_name)</div><div> _engine = module.get_engine()</div><div><br></div><div>As an option we could have the code that loads engine in engine launch script (once we decouple it from API process) so that when we call get_engine() we could pass in all needed configuration parameters like transport.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">3) Modified the engine and the executor to use a factory method to get the global transport</div>
</div></blockquote></div><br><div>If we made a decision on #2 we won’t need it.</div><div><br></div><div><br></div><div>A side note: when we discuss things like that I really miss DI container :)</div><div><br></div><div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><div><br></div></body></html>