a7cd611c78
This change aligns the Mistral documents folder structure to the one specified for Pike [1]. Documents were move to thir appropriate folder, but the different guides do not follow their cookie cutted structure yet. Install guide is in a separate change [2], while I could not found the cookie cutter for the rest of the guides. test-requirements.txt updated with the missing modules. tox_install.sh modified to do not pass $MODULE_NAME and -e parameter to edit-constraints. [1]: http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html [2]: https://review.openstack.org/#/c/476499/ [3]: https://etherpad.openstack.org/p/doc-migration-tracking Change-Id: Ia1101fa2eada446d8eebfefa9bd15d8facd8b3b0 Depends-On: Ia750cb049c0f53a234ea70ce1f2bbbb7a2aa9454 Signed-off-by: csatari <gergely.csatari@nokia.com>
1.7 KiB
Actions
Actions are a particular instruction associated with a task that will be performed when the task runs. For instance: running a shell script, making an HTTP request, or sending a signal to an external system. Actions can be synchronous or asynchronous.
With synchronous actions, Mistral will send a signal to the Mistral Executor and wait for a result. Once the Executor completes the action, the result will be sent to the Mistral Engine.
With asynchronous actions, Mistral will send a signal to a third party service and wait for a corresponding action result to be delivered back via the Mistral API. Once the signal has been sent, Mistral isn't responsible for the state and 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 its state and result.
How to work with asynchronous actions </contributor/asynchronous_actions>
System actions
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.
How to write an Action Plugin </contributor/creating_custom_action>
Ad-hoc actions
Ad-hoc actions are defined in YAML files by users. They wrap existing actions and their main goal is to simplify using the same action multiple times. For example, if the same HTTP request is used in multiple workflows, it can be defined in one place and then re-used without the need to duplicate all of the parameters.
More about actions; actions-dsl.
Note
Nested ad-hoc actions (i.e. ad-hoc actions wrapping around other ad-hoc actions) are not currently supported.