Open Stack

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 <rakhmerov at mirantis.com>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 <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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/f7bff698/attachment.html>