Open Stack

Hi Winson,

Sorry, I haven’t responded so far for I was on vacation. So getting back to you now..

It’s my fault that the notes in the BP are not fairly clear.

1. By “worker parallelism” we meant that one worker (which is called “executor" now) can poll and handle more than one task from the task queue (it’s not abstracted out from the notion of queue but anyway). It would be a nice feature because it would allow to tune the system performance much more accurately.

2. What “engine-executor parallelism” means I honestly don’t remember :) I guess this is a note made by Dmitri so he may be better aware. Dmitri? As far as engine<->executor interaction we now have an issue with it that we need to fix but it’s not related with parallelism. The protocol itself is not 100% complete in terms of reliability.

Thanks

Renat Akhmerov
@ Mirantis Inc.


On 06 Jun 2014, at 23:12, W Chan <m4d.coder at gmail.com> wrote:

> Regarding blueprint https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol, can you clarify what it means by worker parallelism and engine-executor parallelism?  Currently, the engine and executor are launched with the eventlet driver in oslo.messaging.  Once a message arrives over transport, a new green thread is spawned and passed to the dispatcher.  In the case of executor, the function being dispatched to is handle_task.  I'm unclear what additional parallelism this blueprint is referring to.  The context isn't clear from the summit notes.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140618/5dc15404/attachment.html>