Pike Series Release Notes¶
5.2.7¶
Bug Fixes¶
The header X-Target-Insecure previously accepted any string and used it for comparisons. This meant unless it was empty (or not provided) it would always evaluate as True. This change makes the validation stricter, only accepting “True” and “False” and converting these to boolean values. Any other value will return an error.
5.2.6¶
Bug Fixes¶
Cleanup transports along RPC clients. Fixed a bad weird condition in the API server related to cron-triggers and SIGHUP. The parent API server creates a RPC connection when creating workflows from cron triggers. If a SIGUP signal happens after, the child inherits the connection, but it’s non-functional.
5.2.5¶
Bug Fixes¶
Workflow output sometimes was not calculated correctly due to the race condition between different transactions: the one that checks workflow completion (i.e. calls “check_and_complete”) and the one that processes action execution completion (i.e. calls “on_action_complete”). Calculating output sometimes was based on stale data cached by the SQLAlchemy session. To fix this, we just need to expire all objects in the session so that they are refreshed automatically if we read their state in order to make required calculations. The corresponding change was made.
5.2.4¶
Bug Fixes¶
Used “passive_deletes=True” in the configuration of relationships in SQLAlchemy models. This improves deletion of graphs of related objects stored in DB because dependent objects don’t get loaded prior to deletion which also reduces the memory requirement on the system. More about using this flag can be found at: http://docs.sqlalchemy.org/en/latest/orm/collections.html#using-passive-deletes
Mistral was storing, in fact, two copies of a workflow environment, one in workflow parameters (the ‘params’ field) and another one in a context (the ‘context’ field). Now it’s stored only in workflow parameters. It saves space in DB and increases performance in case of big workflow environments.
Mistral was copying a workflow environment into all of their sub workflows. In case of a big workflow environment and a big number of sub workflows it caused serious problems, used additional space in DB and used a lot of RAM (e.g. when the ‘on-success’ clause has a lot of tasks where each one of them is a subworkflow). Now it is fixed by evaluating a workflow environment through the root execution reference.
5.2.3¶
Bug Fixes¶
A regression was introduced that caused an error when logging a specific message. The string formatting was broken, which caused the logging to fail.
Mistral was storing some internal information in task execution inbound context (‘task_executions_v2.in_contex’ DB field) to DB. This information was needed only to correctly implement the YAQL function task() without arguments. A fix was made to not store this information in the persistent storage and rather include it into a context view right before evaluating expressions where needed. So it slightly optimizes spaces in DB.
Evaluation of final workflow context was very heavy in cases when the workflow had a lot of parallel tasks with large inbound contexts. Merging of those contexts in order to evaluate the workflow output consumed a lot of memory. Now this algorithm is rewritten with batched DB query and Python generators so that GS has a chance to destroy objects that have already been processed. Previously all task executions had to stay in memory until the end of the processing. The result is that now it consumes 3 times less memory on heavy cases.
5.0.0¶
New Features¶
Support to specify ‘action_region’ for OpenStack actions so that it’s possible to operate different resources in different regions in one single workflow.
Added ability to create public event triggers. Public event triggers are applied to all projects, i.e. workflows are triggered by event in any project. Currently public event triggers may be created only by admin but it can be changed in policy.json.
Creating and running workflows within a namespace. Workflows with the same name can be added to the same project as long as they are within a different namespace. This feature is backwards compatible.
All existing workflows are assumed to be in the default namespace, represented by an empty string. Also if a workflow is created without a namespace spcified, it is assumed to be in the defualt namespace.
When a workflow is being executed, the namespace is saved under params and passed to all its sub workflow executions. When looking for the next sub-workflow to run, the correct workflow will be found by name and namespace, where the namespace can be the workflow namespace or the default namespace. Workflows in the same namespace as the top workflow will be given a higher priority.
External OpenStack action mapping file could be specified at sync_db.sh or mistral-db-mange script. For more details see ‘sync_db.sh –help’ or ‘mistral-db-manage –help’.
From now it is optional to list openstack modules in mapping file which you would not include into supported action set.
New function, called tasks, available from within an expression (Yaql, Jinja2). This function allows to filter all tasks of a user by workflow execution id and/or state. In addition it is possible to get tasks recursively and flatten the tasks list.
New parameter called ‘include_output’ added to action execution api. By default output field does not return when calling list action executions API
By default, admin user could get/list/update/delete other projects’ resources. In Pike, only workflow/execution are supported.
Mistral action developer can get the start time of a workflow execution by using
<% execution().created_at %>.
The Mistral docker image and tooling has been updated to significantly ease the starting of a Mistral cluster. The setup now supports all-in-one and multi-container deployments. Also, the scripts were cleaned up and aligned with the Docker best practice.
Upgrade Notes¶
Run
python tools/sync_db.py --config-file <mistral-conf-file>to re-populate database.
Deprecation Notes¶
The config option ‘os-actions-endpoint-type’ is moved from DEFAULT group to ‘openstack_actions’ group.
Critical Issues¶
By default, output field will not return when calling list action executions. In the previous version it did, so if a user used this, and/or wants to get output field when calling list action executions API, it will be possible only by using the new include output parameter.
Bug Fixes¶
When we pass a workflow environment to workflow parameters using ‘env’ Mistral first evaluates it assuming that it can contain expressions (YAQL/Jinja) For example, one environment variable can be expressed through the other. In some cases it causes problems. For example, if the environment is too big and has many expressions, especially something like <% $ %> or <% env() %>. Also, in some cases we don’t want any evaluations to happen if we want to have some informative text in the environment containing expressions. In order to address that the ‘evaluate_env’ workflow parameter was added, defaulting to True for backwards compatibility. If it’s set to False then it disables evaluation of expressions in the environment.
Added support for referencing task and workflow context data, including environment variables via env(), when using YAQL/Jinja2 expressions inside AdHoc Actions. YAQL/Jinja2 expressions can reference env() and other context data in the base-input section.
Javascript support in docker image.
