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.co...@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. >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
