Ussuri Series Release Notes¶

10.0.0¶

Mistral engine now supports graceful scale-in. That is, if a number of engines in a cluster needs to be reduced manually it is now possible to do w/o breaking currently running workflows. In order to shutdown a Mistral engine, SIGTERM signal needs to be sent to the corresponding process. In Unix operatating systems it’s a matter of running the command “kill <engine PID>” in any shell. When this signal is caught by the process, it has a certain amount of time configured by the ‘graceful_shutdown_timeout’ property to complete currently running database transactions and process all buffered RPC messages that have already been polled from the queue. After this time elapses, the process will be forced to exit. By default, the value of the ‘graceful_shutdown_timeout’ property is 60 (seconds).

Add support for creating ad-hoc actions in a namespace. Creating actions with same name is now possible inside the same project now. This feature is backward compatible.

All existing actions are assumed to be in the default namespace, represented by an empty string. Also, if an action is created without a namespace specified, it is assumed to be in the default namespace.

If an ad-hoc action is created inside a workbook, then the namespace of the workbook would be also it’s namespace.

Python 2.7 support has been dropped. Last release of mistral to support python 2.7 is OpenStack Train. The minimum version of Python now supported by mistral is Python 3.6.

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.

Fix error validate token when run cron trigger. The problem is that a trust client can’t do validate token when run cron trigger.

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.