Just a clarification: “reverse” flow is what I usually call “dependency based flow” when we specify dependencies between tasks rather then direct transitions (do this then on success do that).
> * 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. I personally would prefer this latest option since I don’t see any rush with refactoring the current API/impl to have two separate workflow types right now. Renat Akhmerov @ Mirantis Inc. On 20 Jun 2014, at 12:33, Dmitri Zimine <dzim...@stackstorm.com> wrote: > 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
