<div dir="ltr">Thanks. I will do that today and follow up with a description of the proposal.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 10:21 PM, 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">“In process” is fine to me.<br>
<br>
Winson, please register a blueprint for this change and put the link in here so that everyone can see what it all means exactly. My feeling is that we can approve and get it done pretty soon.<br>
<span class="HOEnZb"><font color="#888888"><br>
Renat Akhmerov<br>
@ Mirantis Inc.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 25 Feb 2014, at 12:40, Dmitri Zimine <<a href="mailto:dz@stackstorm.com">dz@stackstorm.com</a>> wrote:<br>
<br>
> I agree with Winson's points. Inline.<br>
><br>
> On Feb 24, 2014, at 8:31 PM, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a>> wrote:<br>
><br>
>><br>
>> On 25 Feb 2014, at 07:12, W Chan <<a href="mailto:m4d.coder@gmail.com">m4d.coder@gmail.com</a>> wrote:<br>
>><br>
>>> As I understand, the local engine runs the task immediately whereas the scalable engine sends it over the message queue to one or more executors.<br>
>><br>
>> Correct.<br>
><br>
> Note: that "local" is confusing here, "in process" will reflect what it is doing better.<br>
><br>
>><br>
>>> In what circumstances would we see a Mistral user using a local engine (other than testing) instead of the scalable engine?<br>
>><br>
>> Yes, mostly testing we it could be used for demonstration purposes also or in the environments where installing RabbitMQ is not desirable.<br>
>><br>
>>> If we are keeping the local engine, can we move the abstraction to the executor instead, having drivers for a local executor and remote executor? The message flow from the engine to the executor would be consistent, it's just where the request will be processed.<br>
>><br>
>> I think I get the idea and it sounds good to me. We could really have executor in both cases but the transport from engine to executor can be different. Is that what you’re suggesting? And what do you call driver here?<br>
><br>
> +1 to "abstraction to the executor", indeed the local and remote engines today differ only by how they invoke executor, e.g. transport / driver.<br>
><br>
>><br>
>>> And since we are porting to oslo.messaging, there's already a fake driver that allows for an in process Queue for local execution. The local executor can be a derivative of that fake driver for non-testing purposes. And if we don't want to use an in process queue here to avoid the complexity, we can have the client side module of the executor determine whether to dispatch to a local executor vs. RPC call to a remote executor.<br>
>><br>
>> Yes, that sounds interesting. Could you please write up some etherpad with details explaining your idea?<br>
>><br>
>><br>
>><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>
><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>
<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>
</div></div></blockquote></div><br></div>