Debian Patches
Status for mistral/21.0.0-4
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| install-missing-files.patch | Install missing files | Thomas Goirand <zigo@debian.org> | not-needed | 2018-02-25 | ||
| Load_defaults_from_oslo.concurrency.patch | 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. diff --git a/mistral/config.py b/mistral/config.py index 46ccaa2..01a634c 100644 |
Thomas Goirand <zigo@debian.org> | no | 2025-10-03 | ||
| SSHAction-Add-return_result_on_error.patch | 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. Last-Update:2025-10-15 diff --git a/doc/source/user/wf_lang_v2.rst b/doc/source/user/wf_lang_v2.rst index 1217910..0f4ccbb 100644 |
Thomas Goirand <zigo@debian.org> | yes | 2025-10-12 |