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