I agree with Winson's points. Inline. On Feb 24, 2014, at 8:31 PM, Renat Akhmerov <[email protected]> wrote:
> > On 25 Feb 2014, at 07:12, W Chan <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
