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