Queens Series Release Notes

Queens Series Release Notes

6.0.6-8

New Features

  • 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.

Bug Fixes

  • If an action execution fails but returns a result as a list (error=[]) the result of this action is assigned to the task execution ‘state_info’ field which is a string according to the DB model. On Python 3 it this list magically converts to a string. On Python 2.7 it doesn’t. The reason is probably in how SQLAlchemy works on different versions of Python. This has now been fixed with an explicit type coercion.

6.0.6

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.

6.0.5

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.

6.0.4

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.

6.0.3

Bug Fixes

  • Fixed jinja expression error handling where invalid expression could prevent action or task status to be correctly updated.

  • 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.

6.0.2

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.

6.0.0

New Features

  • A new YAQL/jinja2 expression function has been added for outputting JSON. It is json_dump and accepts one argument, which is the object to be serialised to JSON.

  • Mistral now support policy in code, which means if users didn’t modify any of policy rules, they can leave policy file (in json or yaml format) empty or just remove it all together. Because from now, Mistral keeps all default policies under mistral/policies module. Users can still modify/generate policy.yaml file which will override policy rules in code if those rules show in policy.yaml file.

  • Support to manage a cron-trigger instance by id.

  • Add yaml_parse and json_parse expression functions. Each accepts a string and will parse as either json or yaml, and return an object.

Deprecation Notes

  • The YAQL/jinja2 expression function json_pp has been deprecated and will be removed in the S cycle. json_dump should be used instead.

Bug Fixes

  • Remove ceilometerclient requirement. This library is not maintained and the ceilometer api is dead. So lets drop this integration.

Other Notes

  • Default policy.json file is now removed as Mistral now generate the default policies in code. Please be aware that when using that file in your environment.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.