Open Stack

https://review.openstack.org/#/c/100390/

Angus asked: 
>Why do we even need "start: <start-task>"?
>Can't we parse the workbook and figure out what to run? Tasks at the bottom of the tree have no "on-{fail,success}" and then 
>follow upwards until you find a task that is not referenced by anything.

Yes we can do this (patch almost ready). And It makes a perfect behavior for a direct flow [1]: all the top-level tasks begin to execute in parallel, and dependent tasks scheduled as dependencies resolve. No need to specify . Parallel execution is a default, unless explicitly constrained by on-success/on-error/on-finish. 

But for Reversed flow [2] it’s a BIG change of behavior. Instead of running only a subflow to satisfy a target task, it will run all the tasks (respecting dependencies). This is not practical. 

Eventually we want to support both direct and reverse as two types of workflow, without mixing the two syntaxes within the same workflow. This will require big refactoring (already planned). On the Atlanta summit we agreed to temporarily drop reversed workflow and re-introduce it later. [3] The start task in the API is a big pain for a direct flow. 

How should we proceed? Options I can think of: 

* Drop ‘reverse flow’ right now, stabilize ‘direct flow', reintroduce ‘reverse flow’ later (next cycle).
This will give us a clean final API on a good set of functionality, [almost] immediately. 

* Introduce two workflow types and correspondent API changes/additions on the current code base, before refactoring. 

* Put it off till the engine refactoring, factor the requirement of supporting two modes into the refactoring. It will be easy to do, but takes the longest. 

Other options? Opinions? Requests?

DZ>  


[1] Direct flow has dependencies expressed by on-success/on-error/on-finish keyword on an upstream task
[2] Reverse flow is where dependencies are expressed by requires keyword on a downstream, dependent task
[3] https://etherpad.openstack.org/p/mistral-post-POC-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/aaaface9/attachment.html>