Open Stack

Design proposal for blueprint
https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol


   - Rename Executor to Worker.
   - Continue to use RPC server-client model in oslo.messaging for Engine
   and Worker protocol.
   - Use asynchronous call (cast) between Worker and Engine where
   appropriate.
   - Remove any DB access from Worker.  DB IO will only be done by Engine.
   - Worker updates Engine that it's going to start running action now.  If
   execution is not RUNNING and task is not IDLE, Engine tells Worker to halt
   at this point.  Worker cannot assume execution state is RUNNING and task
   state is IDLE because the handle_task message could have been sitting in
   the message queue for awhile.  This call between Worker and Engine is
   synchronous, meaning Worker will wait for a response from the
Engine.  Currently,
   Executor checks state and updates task state directly to the DB before
   running the action.
   - Worker communicates result (success or failure) to Engine.  Currently,
   Executor is inconsistent and calls Engine.convey_task_result on success and
   write directly to DB on failure.

Sequence


   1. Engine -> Worker.handle_task
   2. Worker converts action spec to Action instance
   3. Worker -> Engine.confirm_task_execution. Engine returns an exception
   if execution state is not RUNNING or task state is not IDLE.
   4. Worker runs action
   5. Worker -> Engine.convey_task_result

Please provide feedback.

Thanks.
Winson




On Fri, Jun 6, 2014 at 9:12 AM, W Chan <m4d.coder at gmail.com> wrote:

> Renat,
>
> 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.
>
> Thanks.
> Winson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140612/4bd6f7b2/attachment.html>