<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"><br></div><div><div>On 13 Mar 2014, at 10:40, W Chan <<a href="mailto:m4d.coder@gmail.com">m4d.coder@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><ul><li>I can write a method in base test to start local executor. I will do that as a separate bp. <br></li></ul></div></blockquote>Ok.<br><blockquote type="cite"><div dir="ltr"><ul><li>After the engine is made standalone, the API will communicate to the engine and the engine to the executor via the oslo.messaging transport. This means that for the "local" option, we need to start all three components (API, engine, and executor) on the same process. If the long term goal as you stated above is to use separate launchers for these components, this means that the API launcher needs to duplicate all the logic to launch the engine and the executor. Hence, my proposal here is to move the logic to launch the components into a common module and either have a single generic launch script that launch specific components based on the CLI options or have separate launch scripts that reference the appropriate launch function from the common module.<br></li></ul></div></blockquote><div>Ok, I see your point. Then I would suggest we have one script which we could use to run all the components (any subset of of them). So for those components we specified when launching the script we use this local transport. Btw, scheduler eventually should become a standalone component too, so we have 4 components.</div><br><blockquote type="cite"><div dir="ltr"><ul><li>The RPC client/server in oslo.messaging do not determine the transport. The transport is determine via oslo.config and then given explicitly to the RPC client/server. <a href="https://github.com/stackforge/mistral/blob/master/mistral/engine/scalable/engine.py#L31">https://github.com/stackforge/mistral/blob/master/mistral/engine/scalable/engine.py#L31</a> and <a href="https://github.com/stackforge/mistral/blob/master/mistral/cmd/task_executor.py#L63">https://github.com/stackforge/mistral/blob/master/mistral/cmd/task_executor.py#L63</a> are examples for the client and server respectively. The in process Queue is instantiated within this transport object from the fake driver. For the "local" option, all three components need to share the same transport in order to have the Queue in scope. Thus, we will need some method to have this transport object visible to all three components and hence my proposal to use a global variable and a factory method. </li>
</ul></div></blockquote></div>I’m still not sure I follow your point here.. Looking at the links you provided I see this:<div><br></div><div><span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">transport</span><span style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre; background-color: rgb(255, 255, 204);"> </span><span class="o" style="box-sizing: border-box; font-weight: bold; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">=</span><span style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre; background-color: rgb(255, 255, 204);"> </span><span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">messaging</span><span class="o" style="box-sizing: border-box; font-weight: bold; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">.</span><span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">get_transport</span><span class="p" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">(</span><span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">cfg</span><span class="o" style="box-sizing: border-box; font-weight: bold; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">.</span><span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">CONF</span><span class="p" style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Courier, monospace; line-height: 18px; white-space: pre;">)</span></div><div><br></div><div>So my point here is we can make this call once in the launching script and pass it to engine/executor (and now API too if we want it to be launched by the same script). Of course, we’ll have to change the way how we initialize these components, but I believe we can do it. So it’s just a dependency injection. And in this case we wouldn’t need to use a global variable. Am I still missing something?</div><div><br></div><div><br></div><div><div>Renat Akhmerov</div><div>@ Mirantis Inc.</div></div><div><br></div></body></html>