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