<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;">Take a look at method get_pecan_config() in mistral/api/app.py. It’s where you can pass any parameters into pecan app (see a dictionary ‘cfg_dict’ initialization). They can be then accessed via pecan.conf as described here: <a href="http://pecan.readthedocs.org/en/latest/configuration.html#application-configuration">http://pecan.readthedocs.org/en/latest/configuration.html#application-configuration</a>. If I understood the problem correctly this should be helpful.<br><div><br><div><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br class="Apple-interchange-newline">
</div>
<br><div><div>On 14 Mar 2014, at 05:14, Dmitri Zimine <<a href="mailto:dz@stackstorm.com">dz@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We have access to all configuration parameters in the context of api.py. May be you don't pass it but just instantiate it where you need it? Or I may misunderstand what you're trying to do...<div><br></div><div>DZ> </div><div><br></div><div>PS: can you generate and update mistral.config.example to include new oslo messaging options? I forgot to mention it on review on time. </div><div><br></div><div><br><div><div>On Mar 13, 2014, at 11:15 AM, 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">On the transport variable, the problem I see isn't with passing the variable to the engine and executor. It's passing the transport into the API layer. The API layer is a pecan app and I currently don't see a way where the transport variable can be passed to it directly. I'm looking at <a href="https://github.com/stackforge/mistral/blob/master/mistral/cmd/api.py#L50">https://github.com/stackforge/mistral/blob/master/mistral/cmd/api.py#L50</a> and <a href="https://github.com/stackforge/mistral/blob/master/mistral/api/app.py#L44">https://github.com/stackforge/mistral/blob/master/mistral/api/app.py#L44</a>. Do you have any suggestion? Thanks. </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 1:30 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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><br></div><div><div class=""><div>On 13 Mar 2014, at 10:40, 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"><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></div>Ok.<div class=""><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><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>
<div class=""><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" target="_blank">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" target="_blank">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></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 style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">transport</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap;background-color:rgb(255,255,204)"> </span><span style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">=</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap;background-color:rgb(255,255,204)"> </span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">messaging</span><span style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">.</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">get_transport</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">(</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">cfg</span><span style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">.</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">CONF</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;line-height:18px;white-space:pre-wrap">)</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 class=""><div><br></div><div><br></div><div><div>Renat Akhmerov</div><div>@ Mirantis Inc.</div></div><div><br></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>
_______________________________________________<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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote></div><br></div></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></div></div></body></html>