Open Stack

“In process” is fine to me.

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.

Renat Akhmerov
@ Mirantis Inc.



On 25 Feb 2014, at 12:40, Dmitri Zimine <dz at stackstorm.com> wrote:

> I agree with Winson's points. Inline.
> 
> On Feb 24, 2014, at 8:31 PM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:
> 
>> 
>> On 25 Feb 2014, at 07:12, W Chan <m4d.coder at gmail.com> wrote:
>> 
>>> 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.  
>> 
>> Correct.
> 
> Note: that "local" is confusing here, "in process" will reflect what it is doing better. 
> 
>> 
>>> In what circumstances would we see a Mistral user using a local engine (other than testing) instead of the scalable engine?
>> 
>> Yes, mostly testing we it could be used for demonstration purposes also or in the environments where installing RabbitMQ is not desirable.
>> 
>>> 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.  
>> 
>> 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?
> 
> +1 to "abstraction to the executor", indeed the local and remote engines today differ only by how they invoke executor, e.g. transport / driver.
> 
>> 
>>> 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.
>> 
>> Yes, that sounds interesting. Could you please write up some etherpad with details explaining your idea?
>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev