On 25 Feb 2014, at 07:12, W Chan <m4d.co...@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. > 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? > 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
