Adjust images in the docs and other small fixes
* Some ".. image:" RST directives changed to ".. figure:" where it's more suitable. * All images moved to subfolder where they're used * Fixed indentation in the Workflow Language specification * Other minor changes in docs Change-Id: If2f206a5191d1eecdcf95e1f7b44a87968432876
|
@ -6,7 +6,7 @@ How to work with asynchronous actions
|
||||||
Concept
|
Concept
|
||||||
*******
|
*******
|
||||||
|
|
||||||
.. image:: /img/Mistral_actions.png
|
.. image:: /user/terminology/img/actions.png
|
||||||
|
|
||||||
During a workflow execution Mistral eventually runs actions. Action
|
During a workflow execution Mistral eventually runs actions. Action
|
||||||
is a particular function (or a piece of work) that a workflow task
|
is a particular function (or a piece of work) that a workflow task
|
||||||
|
|
|
@ -64,8 +64,10 @@ script running on a single machine that is responsible for solving this
|
||||||
task just fails for whatever reason then the whole process of updating
|
task just fails for whatever reason then the whole process of updating
|
||||||
a hundred servers will not complete and end up in an unknown state.
|
a hundred servers will not complete and end up in an unknown state.
|
||||||
|
|
||||||
.. image:: img/cloud_cron_updating_multiple_servers.png
|
.. figure:: img/cloud_cron_updating_multiple_servers.png
|
||||||
:alt: Updating multiple tenant servers
|
:align: center
|
||||||
|
|
||||||
|
Figure 1. Updating multiple tenant servers
|
||||||
|
|
||||||
So that shows that we need to take care of at least:
|
So that shows that we need to take care of at least:
|
||||||
|
|
||||||
|
@ -192,8 +194,10 @@ we can actually ssh other VMs. That's why we're using special action called
|
||||||
"std.ssh_proxied" where "proxied" means that we have a proxy VM to access
|
"std.ssh_proxied" where "proxied" means that we have a proxy VM to access
|
||||||
all tenant VMs.
|
all tenant VMs.
|
||||||
|
|
||||||
.. image:: img/ssh_proxied.png
|
.. figure:: img/ssh_proxied.png
|
||||||
:alt: Ssh access through a gateway VM
|
:align: center
|
||||||
|
|
||||||
|
Figure 2. Ssh access through a gateway VM.
|
||||||
|
|
||||||
Mistral is a distributed highly-available system and it’s designed not only
|
Mistral is a distributed highly-available system and it’s designed not only
|
||||||
to survive infrastructural failures but also keep its workflows running.
|
to survive infrastructural failures but also keep its workflows running.
|
||||||
|
|
|
@ -17,7 +17,7 @@ result of the action. The third-party service should send a request to the
|
||||||
Mistral API and provide information corresponding to the *action execution* and
|
Mistral API and provide information corresponding to the *action execution* and
|
||||||
its state and result.
|
its state and result.
|
||||||
|
|
||||||
.. image:: /img/Mistral_actions.png
|
.. image:: img/actions.png
|
||||||
|
|
||||||
:doc:`How to work with asynchronous actions </user/asynchronous_actions>`
|
:doc:`How to work with asynchronous actions </user/asynchronous_actions>`
|
||||||
|
|
||||||
|
@ -27,7 +27,7 @@ System actions
|
||||||
System actions are provided by Mistral out of the box and are available to all
|
System actions are provided by Mistral out of the box and are available to all
|
||||||
users. Additional actions can be added via the custom action plugin mechanism.
|
users. Additional actions can be added via the custom action plugin mechanism.
|
||||||
|
|
||||||
:doc:`How to write an Action Plugin
|
:doc:`How to create a custom action
|
||||||
</developer/extensions/creating_custom_action>`
|
</developer/extensions/creating_custom_action>`
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -5,8 +5,9 @@ Cron trigger is an object allowing to run workflow on a schedule. User
|
||||||
specifies what workflow with what input needs to be run and also specifies
|
specifies what workflow with what input needs to be run and also specifies
|
||||||
how often it should be run.
|
how often it should be run.
|
||||||
|
|
||||||
.. image:: /img/Mistral_cron_trigger.png
|
.. image:: img/cron_trigger.png
|
||||||
:align: center
|
:align: center
|
||||||
|
|
||||||
Cron-pattern is used to describe the frequency of execution in Mistral.
|
Cron-pattern is used to describe the frequency of execution in Mistral.
|
||||||
To see more about cron-patterns, refer to `Cron expression <https://en.wikipedia.org/wiki/Cron#CRON_expression>`_
|
To see more about cron-patterns, refer to
|
||||||
|
`Cron expression <https://en.wikipedia.org/wiki/Cron#CRON_expression>`_
|
||||||
|
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 3.3 KiB After Width: | Height: | Size: 3.3 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
@ -18,7 +18,7 @@ name as a prefix for generating final names of workflows and actions included
|
||||||
into the workbook. To illustrate this principle let's take a look at the
|
into the workbook. To illustrate this principle let's take a look at the
|
||||||
figure below:
|
figure below:
|
||||||
|
|
||||||
.. image:: /img/Mistral_workbook_namespacing.png
|
.. image:: img/workbook_namespacing.png
|
||||||
:align: center
|
:align: center
|
||||||
|
|
||||||
So after a workbook has been uploaded its workflows and actions become
|
So after a workbook has been uploaded its workflows and actions become
|
||||||
|
|
|
@ -56,7 +56,7 @@ workflow has a notion of transition. Direct workflow is considered to be
|
||||||
completed if there aren't any transitions left that could be used to
|
completed if there aren't any transitions left that could be used to
|
||||||
jump to next tasks.
|
jump to next tasks.
|
||||||
|
|
||||||
.. image:: /img/Mistral_direct_workflow.png
|
.. image:: img/direct_workflow.png
|
||||||
|
|
||||||
YAML example of direct workflow
|
YAML example of direct workflow
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
@ -97,7 +97,7 @@ task that needs to be completed, it can be conventionally called 'target
|
||||||
task'. When Mistral Engine starts a workflow it recursively identifies
|
task'. When Mistral Engine starts a workflow it recursively identifies
|
||||||
all the dependencies that need to be completed first.
|
all the dependencies that need to be completed first.
|
||||||
|
|
||||||
.. image:: /img/Mistral_reverse_workflow.png
|
.. image:: img/reverse_workflow.png
|
||||||
|
|
||||||
The figure explains how reverse workflow works. In the example, task
|
The figure explains how reverse workflow works. In the example, task
|
||||||
**T1** is chosen a target task. So when the workflow starts Mistral will
|
**T1** is chosen a target task. So when the workflow starts Mistral will
|
||||||
|
|
|
@ -43,10 +43,11 @@ Mistral is a perfect fit for being this kind of coordinator. In order to
|
||||||
illustrate everything described so far, let’s consider an imaginary workflow
|
illustrate everything described so far, let’s consider an imaginary workflow
|
||||||
of calculating employees’ salaries in an enterprise.
|
of calculating employees’ salaries in an enterprise.
|
||||||
|
|
||||||
.. image:: img/long_running_business_process.png
|
.. figure:: img/long_running_business_process.png
|
||||||
:alt: Picture 1. Mistral maintains business workflows spanning multiple systems.
|
|
||||||
:align: center
|
:align: center
|
||||||
|
|
||||||
|
Figure 1. Mistral maintains business workflows spanning multiple systems.
|
||||||
|
|
||||||
Given an employee full name (or id) such workflow may include the following
|
Given an employee full name (or id) such workflow may include the following
|
||||||
computation steps:
|
computation steps:
|
||||||
|
|
||||||
|
|
|
@ -532,7 +532,7 @@ starts after another one depending on produced result. So direct workflow has a
|
||||||
notion of transition. Direct workflow is considered to be completed if there
|
notion of transition. Direct workflow is considered to be completed if there
|
||||||
aren't any transitions left that could be used to jump to next tasks.
|
aren't any transitions left that could be used to jump to next tasks.
|
||||||
|
|
||||||
.. image:: /img/Mistral_direct_workflow.png
|
.. image:: /user/terminology/img/direct_workflow.png
|
||||||
|
|
||||||
Figure 1. Mistral Direct Workflow.
|
Figure 1. Mistral Direct Workflow.
|
||||||
|
|
||||||
|
@ -962,7 +962,7 @@ be completed, it can be conventionally called 'target task'. When Mistral
|
||||||
Engine starts a workflow it recursively identifies all the dependencies that
|
Engine starts a workflow it recursively identifies all the dependencies that
|
||||||
need to be completed first.
|
need to be completed first.
|
||||||
|
|
||||||
.. image:: /img/Mistral_reverse_workflow.png
|
.. image:: /user/terminology/img/reverse_workflow.png
|
||||||
|
|
||||||
Figure 2 explains how reverse workflow works. In the example, task **T1** is
|
Figure 2 explains how reverse workflow works. In the example, task **T1** is
|
||||||
chosen a target task. So when the workflow starts Mistral will run only tasks
|
chosen a target task. So when the workflow starts Mistral will run only tasks
|
||||||
|
@ -1421,7 +1421,7 @@ name as a prefix for generating final names of workflows, actions and triggers
|
||||||
included into the workbook. To illustrate this principle let's take a look at
|
included into the workbook. To illustrate this principle let's take a look at
|
||||||
the figure below.
|
the figure below.
|
||||||
|
|
||||||
.. image:: /img/Mistral_workbook_namespacing.png
|
.. image:: /user/terminology/img/workbook_namespacing.png
|
||||||
|
|
||||||
So after a workbook has been uploaded its workflows and actions become
|
So after a workbook has been uploaded its workflows and actions become
|
||||||
independent objects but with slightly different names.
|
independent objects but with slightly different names.
|
||||||
|
@ -1526,36 +1526,36 @@ Signature:
|
||||||
|
|
||||||
Description:
|
Description:
|
||||||
|
|
||||||
This function allows users to filter all tasks by workflow execution id
|
This function allows users to filter all tasks by workflow execution id
|
||||||
and/or state. In addition, it is possible to get task executions recursively
|
and/or state. In addition, it is possible to get task executions recursively
|
||||||
and flatten the task executions list.
|
and flatten the task executions list.
|
||||||
|
|
||||||
Parameters:
|
Parameters:
|
||||||
|
|
||||||
#. **workflow_execution_id** - If provided the tasks function will return
|
#. **workflow_execution_id** - If provided the tasks function will return
|
||||||
task executions for a specific workflow execution (either the current
|
task executions for a specific workflow execution (either the current
|
||||||
execution or a different one). Otherwise it will return all task
|
execution or a different one). Otherwise it will return all task
|
||||||
executions that match the other parameters. *Optional.*
|
executions that match the other parameters. *Optional.*
|
||||||
#. **recursive** - This parameter is a boolean value, if it is true then all
|
#. **recursive** - This parameter is a boolean value, if it is true then all
|
||||||
task executions within nested workflow executions will be returned. This
|
task executions within nested workflow executions will be returned. This
|
||||||
is usually used in combination with a specific workflow_execution_id
|
is usually used in combination with a specific workflow_execution_id
|
||||||
where you still want to see nested workflow's task executions. *Optional.*
|
where you still want to see nested workflow's task executions. *Optional.*
|
||||||
False by default.
|
False by default.
|
||||||
#. **state** - If provided, the task executions will be filtered by their
|
#. **state** - If provided, the task executions will be filtered by their
|
||||||
current state. If state isn't provided, all task executions that match the
|
current state. If state isn't provided, all task executions that match the
|
||||||
other parameters will be returned . *Optional.*
|
other parameters will be returned . *Optional.*
|
||||||
#. **flat** - if true, only list the task executions that match at least one
|
#. **flat** - if true, only list the task executions that match at least one
|
||||||
of the next conditions:
|
of the next conditions:
|
||||||
|
|
||||||
* task executions of type action
|
* task executions of type action
|
||||||
* task executions of type workflow that have a different state from the
|
* task executions of type workflow that have a different state from the
|
||||||
workflow execution they triggered. For example, if used with a
|
workflow execution they triggered. For example, if used with a
|
||||||
specific workflow_execution_id and the state ERROR it will return
|
specific workflow_execution_id and the state ERROR it will return
|
||||||
tasks that erred despite the workflow succeeding. This can mean that
|
tasks that erred despite the workflow succeeding. This can mean that
|
||||||
there was an error in the task itself, like an invalid expression in
|
there was an error in the task itself, like an invalid expression in
|
||||||
publish.
|
publish.
|
||||||
|
|
||||||
*Optional.* False by default.
|
*Optional.* False by default.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
@ -1585,10 +1585,6 @@ Workflow definition:
|
||||||
|
|
||||||
Task publish result (partial to keep the documentation short):
|
Task publish result (partial to keep the documentation short):
|
||||||
|
|
||||||
.. warning::
|
|
||||||
The return value for each task execution hasn't been finalized and isn't
|
|
||||||
considered stable. It may change in a future Mistral release.
|
|
||||||
|
|
||||||
.. code-block:: json
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
|
@ -1679,34 +1675,34 @@ Signature:
|
||||||
|
|
||||||
Description:
|
Description:
|
||||||
|
|
||||||
This function allows users to filter all executions by execution id,
|
This function allows users to filter all executions by execution id,
|
||||||
root_execution_id ,state and/or created_at time.
|
root_execution_id ,state and/or created_at time.
|
||||||
|
|
||||||
Parameters:
|
Parameters:
|
||||||
|
|
||||||
#. **id** - If provided will return a list of executions with that id.
|
#. **id** - If provided will return a list of executions with that id.
|
||||||
Otherwise it will return all executions that match the other
|
Otherwise it will return all executions that match the other
|
||||||
parameters. *Optional.*
|
parameters. *Optional.*
|
||||||
#. **root_execution_id** - Similar to id above, if provided will return
|
#. **root_execution_id** - Similar to id above, if provided will return
|
||||||
a list of executions with that root_execution_id. Otherwise it will
|
a list of executions with that root_execution_id. Otherwise it will
|
||||||
return all executions that match the other parameters. *Optional.*
|
return all executions that match the other parameters. *Optional.*
|
||||||
False by default.
|
False by default.
|
||||||
#. **state** - If provided, the executions will be filtered by their
|
#. **state** - If provided, the executions will be filtered by their
|
||||||
current state. If state isn't provided, all executions that match the
|
current state. If state isn't provided, all executions that match the
|
||||||
other parameters will be returned . *Optional.*
|
other parameters will be returned . *Optional.*
|
||||||
#. **from_time** - If provided, the executions will be filtered by their
|
#. **from_time** - If provided, the executions will be filtered by their
|
||||||
created_at time being greater or equal to the from_time parameter.
|
created_at time being greater or equal to the from_time parameter.
|
||||||
If from_time isn't provided, all executions that match the
|
If from_time isn't provided, all executions that match the
|
||||||
other parameters will be returned. from_time parameter can be provided
|
other parameters will be returned. from_time parameter can be provided
|
||||||
in the format *YYYY-MM-DD hh:mm:ss*
|
in the format *YYYY-MM-DD hh:mm:ss*
|
||||||
*Optional.*
|
*Optional.*
|
||||||
#. **to_time** - If provided, the executions will be filtered by their
|
#. **to_time** - If provided, the executions will be filtered by their
|
||||||
created_at time being less than to the from_time parameter (less than but
|
created_at time being less than to the from_time parameter (less than but
|
||||||
not less than equal as the from_time parameter does)
|
not less than equal as the from_time parameter does)
|
||||||
If to_time isn't provided, all executions that match the
|
If to_time isn't provided, all executions that match the
|
||||||
other parameters will be returned. to_time parameter can be provided
|
other parameters will be returned. to_time parameter can be provided
|
||||||
in the format *YYYY-MM-DD hh:mm:ss*
|
in the format *YYYY-MM-DD hh:mm:ss*
|
||||||
*Optional.*
|
*Optional.*
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
|