MANIFEST.in | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 install missing files

mistral/config.py | 9 9 + 0 - 0 !
tools/config/config-generator.mistral.conf | 1 1 + 0 - 0 !
2 files changed, 10 insertions(+)

 load defaults from oslo.concurrency
 Under my env (ie: Debian packages), I've seen mistral-api trying to
 write under:
 .
 /var/lock/nova/oslo_read_shm_<HOSTNAME>_mistral-api
 .
 Why /var/lock/nova is a mistery, but I want to fix this.
 .
 This patch:
 .
 Ensures oslo.concurrency lockutils uses the value from the parsed config.
 oslo.concurrency registers its opts on import, so the option exists;
 call set_defaults *after* CONF(...) so we pick up any value from files.
 .
 Sets the lockutils default to the configured path so external locks
 (synchronized(external=True)) use the right directory.
Signed-off-by: Thomas Goirand <zigo@debian.org>

doc/source/user/wf_lang_v2.rst | 51 51 + 0 - 0 !
mistral/actions/std_actions.py | 33 27 + 6 - 0 !
mistral/tests/unit/actions/test_std_ssh_action.py | 161 153 + 8 - 0 !
releasenotes/notes/SSHAction-return_result_on_error-631427c7af28ced7.yaml | 7 7 + 0 - 0 !
4 files changed, 238 insertions(+), 14 deletions(-)

 sshaction: add return_result_on_error=true/false
 Currently, if an SSHAction is launched, and the target script returns
 with non-zero, the execution will be set to ERROR, and we can see in
 the "execution output show":
 .
 "The action raised an exception
 [action=<mistral.actions.std_actions.SSHAction object at 0x1234>,
 action_ex_id=<UUID>, msg='Failed to execute ssh cmd
 '/path/to/command param1 param2' on ['hostname']']"
 .
 That's not at all helpful for debugging, as the command stdout
 and stderr aren't accessible anymore. One may want to have the ssh
 output instead, and see what went wrong.
 .
 This patch adds a return_result_on_error new param to have the
 feature (and to keep backward compatibility). When this is set,
 when an SSH command is launched correctly, but returns non-zero,
 the output will contain the stdout, stderr and return code.
 Because of Mistral's design, the workflow execusion task cannot
 be en ERROR, otherwise stdout/stderr/exit_code are overwritten
 by Mistral exception. Therefore, if one wants to still have the
 workflow execution in error, the exit code must be looked-up
 later in the workflow. Lookup in the doc change included in
 this patch.