Open Stack

On 10/9/2013 12:55 PM, Joshua Harlow wrote:
> Your example sounds a lot like what taskflow is build for doing.
>
> https://github.com/stackforge/taskflow/blob/master/taskflow/examples/calculate_in_parallel.py is
> a decent example.
>
> In that one, tasks are created and input/output dependencies are
> specified (provides, rebind, and the execute function arguments itself).
>
> This is combined into the taskflow concept of a flow, one of those flows
> types is a dependency graph.
>
> Using a parallel engine (similar in concept to a heat engine) we can run
> all non-dependent tasks in parallel.
>
> An example that I just created that shows this (and shows it running)
> that closer matches your example.
>
> Program (this will work against the current taskflow
> codebase): http://paste.openstack.org/show/48156/
>

I think that there is a major difference between building a set of 
virtual servers (what Heat does) and performing a specific task on
a set of servers (what taskflow is designed for).

Taskflow is currently planned to have a more complex and robust
state machine that what Heat plans. This is natural given that
simplicity has a relatively higher value for deployment, while
efficiency of execution matters more for a task that will be
performed repeatedly.

However, if a simpler state model is needed, keep in mind that
a simpler interface can always be translated into the more complete
interface with a shim layer. You cannot build a more flexible solution
on top of a simple solution.