Mitaka Series Release Notes

2.0.0

Prelude

Pre-installed Mistral docker image is now available to get quick idea of Mistral.

Tempest plugin has been implemented. Now Mistral tests can be run from Mistral repo as well as from Tempest repo.

Actions of several OpenStack services are supported out of the box in Mitaka, including Barbican, Cinder(V2), Swift, Trove, Zaqar and Mistral.

New Features

  • Add support for workflow sharing feature. users of one project can share workflows to other projects using this feature.

Upgrade Notes

  • During an upgrade to Mitaka, operators or administrators need to run python tools/get_action_list.py <service name> command to generate service action names and values for updating mistral/actions/openstack/mapping.json, then, run python tools/sync_db.py to populate database. Please note, some services like Neutron, Swift, Zaqar don’t support the command yet.

Deprecation Notes

  • Usage of workflow name in the system(e.g. creating executions/cron-triggers , workfow CRUD operations, etc.) is deprecated, please use workflow UUID instead. The workflow sharing feature can only be used with workflow UUID.

Security Issues

  • [bug 1521802] Fixing the problem that sometimes sub-workflow executions were run/saved under the wrong tenant in cron trigger periodic task in multi-tenancy deployment.

Bug Fixes

  • [bug 1518012] [bug 1513456]

    Fix concurrency issues by using READ_COMMITTED

    This release note describes bugs:

    • #1513456 - task stuck in RUNNING state when all action executions are finished regarding the problem and the fix.

    • #1518012- WF execution stays in RUNNING although task and action executions are in SUCCESS.

    This fix does not require any action from Mistral users and does not have any implications other than the bug fix.

    The state of a workflow execution was not updated even when all task executions were completed if some tasks finished at the same time as other tasks.

    Because we were using our connections with transaction isolation level = REPEATABLE_READ - Each process was using a snapshot of the DB created at the first read statement in that transaction. When a task finished and evaluated the state of all the other tasks it did not see the up-to-date state of those tasks - and so, because not all tasks were completed - the task did not change the workflow execution state.

    Similar behavior happened with multiple action executions under same task. On completion, each action execution checked the status of the other action executions and did not see the up-to-date state of these action execution - causing task execution to stay in RUNNING state.

    The solution is to change DB transaction isolation level from REPEATABLE_READ to READ_COMMITTED so process A can see changes committed in other transactions even if process A is in the middle of a transaction.

    A short explanation regarding the different isolation levels:


    • REPEATABLE_READ - while in transaction, the first read operation to the DB creates a snapshot of the entire DB so you are guarantee that all the data in the DB will remain the same until the end of the transaction.

      REPEATABLE_READ example:

      • ConnectionA selects from tableA in a transaction.

      • ConnectionB deletes all rows from tableB in a transaction.

      • ConnectionB commits.

      • ConnectionA loops over the rows of tableA and fetches from tableB using the tableA_tableB_FK - ConnectionA will get rows from tableB.


    • READ_COMMITTED - while in a transaction, every query to the DB will get the committed data.

      READ_COMMITTED example:

      • ConnectionA starts a transaction.

      • ConnectionB starts a transaction.

      • ConnectionA insert row to tableA and commits.

      • ConnectionB insert row to tableA.

      • ConnectionB selects tableA and gets two rows.

      • ConnectionB commits / rollback.

    Two good articles about isolation levels are: