diff options
| author | Jenkins <jenkins@review.openstack.org> | 2015-02-15 10:58:43 +0000 |
|---|---|---|
| committer | Gerrit Code Review <review@openstack.org> | 2015-02-15 10:58:43 +0000 |
| commit | d70c04a3c985e704b0174d53367316ebb3234a84 (patch) | |
| tree | 453cf050c72a8ecee9983cac1a4efe236c63a6a4 | |
| parent | 5ee7e94e5ecbbfae90e969f040e4c5b6d31d3dfa (diff) | |
| parent | 1ca123bfd587d5e92091237cb2f25e999136fb7a (diff) | |
| download | taskflow-d70c04a3c985e704b0174d53367316ebb3234a84.tar.gz | |
Merge "Remove duplicate 'the' and link to worker engine section"
| -rw-r--r-- | doc/source/engines.rst | 12 |
1 files changed, 7 insertions, 5 deletions
diff --git a/doc/source/engines.rst b/doc/source/engines.rst index 9e931ad..59a2869 100644 --- a/doc/source/engines.rst +++ b/doc/source/engines.rst @@ -37,7 +37,7 @@ imperative model involves establishing statements that accomplish a programs action (likely using conditionals and such other language features to do this). This kind of program embeds the *how* to accomplish a goal while also defining *what* the goal actually is (and the state of this is maintained in memory or -on the stack while these statements execute). In contrast there is the the +on the stack while these statements execute). In contrast there is the declarative model which instead of combining the *how* to accomplish a goal along side the *what* is to be accomplished splits these two into only declaring what the intended goal is and not the *how*. In TaskFlow terminology @@ -59,10 +59,10 @@ declarative model) allows for the following functionality to become possible: get back into that state when resumption occurs. * Enhancing scalability: When a engine is responsible for executing your desired work it becomes possible to alter the *how* in the future by creating - new types of execution backends (for example the worker model which does not - execute locally). Without the decoupling of the *what* and the *how* it is - not possible to provide such a feature (since by the very nature of that - coupling this kind of functionality is inherently hard to provide). + new types of execution backends (for example the `worker`_ model which does + not execute locally). Without the decoupling of the *what* and the *how* it + is not possible to provide such a feature (since by the very nature of that + coupling this kind of functionality is inherently very hard to provide). * Enhancing consistency: Since the engine is responsible for executing atoms and the associated workflow, it can be one (if not the only) of the primary entities that is working to keep the execution model in a consistent state. @@ -185,6 +185,8 @@ using your desired execution model. Workers ------- +.. _worker: + **Engine type**: ``'worker-based'`` or ``'workers'`` .. note:: Since this engine is significantly more complicated (and |