Thanks. I will do that today and follow up with a description of the proposal.
On Mon, Feb 24, 2014 at 10:21 PM, Renat Akhmerov <[email protected]>wrote: > "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 <[email protected]> wrote: > > > 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 > > > _______________________________________________ > 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
