Train Series Release Notes¶

9.1.0¶

Added the configuration option “convert_output_data” in the “yaql” group. This option, if set to False, allows to disable YAQL expression result conversion. This fixes performance issues for lots of use cases where a result of an expression is a big data structure. In fact, YAQL created a copy of this data structure every time before giving it to Mistral. This option can’t be set to False when the corresponding “convert_input_data” is True. Otherwise, it doesn’t work correctly. By default, the value of “convert_output_data” is True which keeps backwards compatibility.

Some users rely on the presence of the root error related to running an action and it’s not convenient that it is now in the end of the string, e.g. if we look at the corresponding task execution “state_info” field. Now a cause error message is included in the beginning of the resulting error string returned by the action executor so that it’s clearly visible. This message can be also truncated in some cases (depending on the config option) so we need to make sure we keep the cause error message.

This makes getting a root_execution_id available to the jinja execution object. Before this it was only possible to get that through filtering and querying the executions search.

The new configuration option “validation_mode” was added. It can take one of the values: “enabled”, “mandatory”, “disabled”. If it is set to “enabled” then Mistral will be validating the workflow language syntax for all API operations that create or update workflows (either via /v2/workflows or /v2/workbooks) unless it’s explicitly disabled with the API parameter “skip_validation” that has now been added to the corresponding API endpoints. The “skip_validation” parameter doesn’t have to have any value since it’s a boolean flag. If the configuration option “validation_mode” is set to “mandatory” then Mistral will be always validating the syntax of all workflows for the mentioned operations. If set to “disabled” then validation will always be skipped. Note that if validation is disabled (one way or another) then there’s a risk of breaking a workflow unexpectedly while it’s running or getting another an unexpected error when uploading it possible w/o a user-friendly description of the error.

Added HTTPProxyToWSGI middleware in front of the Mistral API. The purpose of this middleware is to set up the request URL correctly in the case there is a proxy (for instance, a loadbalancer such as HAProxy) in front of the Mistral API. The HTTPProxyToWSGI is off by default and needs to be enabled via a configuration value. Fixes [bug 1590608] Fixes [bug 1816364]

Adds the parameter private_key in the standard ssh actions. This allows a user to specify the key to use instead of using the ones available in the filesystem of the executors.

Added the “convert_input_data” config property under the “yaql” group. By default it’s set to True which preserves the current behavior so there’s no risk with compatibility. If set to False, it disables the additional data conversion that was initially added to support some tricky cases like working with sets of dicts (although dict is not a hashable type and can’t be put into a set). Disabling it give a significant performance boost in cases when data contexts are very large.

There was a weird typo in the list generator expression made in https://review.opendev.org/#/c/652575 that led to calculating a field value in the wrong way. Fixed. The added test was previously failing.

“__task_execution” wasn’t always included into the expression data context so the function task() didn’t work properly. Fixes [bug 1823875]

For an ad-hoc action, preparing input for its base action was done more than once. It happened during the validation phase and the scheduling phase. However, input preparation may be expensive in case of heavy expressions and data contexts. This has now been fixed by caching a prepared input within an AdHocAction instance.

WorkflowExecution database model had only “root_execution_id” to reference a root workflow execution, i.e. the most parent workflow execution in the execution tree. So if we needed to get an entity itself we’d always make a direct query to the database, in fact, w/o using an entity cache in the SQLAlchemy session. It’s now been fixed by adding a normal mapped entity for root workflow execution. In other words, WorkflowExecution class now has the property “root_execution”. It slightly improves performance in case this property is accessed more than once per the database session.