April 16, 2018
by Tomaz Muraus
Spring is here and with that we are happy to announce a new StackStorm release: v2.7. This release includes various new features, improvements and bug-fixes. The biggest change you’ll notice is improved Mistral performance. Read on for more details on this, and everything else we’ve done:
Note: StackStorm 2.7.1 was released a few days after 2.7.0. This fixed two small issues, one related to the release of Pip 10.0. If you installed StackStorm v2.7.0, you should upgrade to v2.7.1.
One of the bigger changes included in this release is how we retrieve results for Mistral workflows.
In the previous versions, we used the
st2resultstracker service which would periodically poll Mistral for results of the completed workflows and store that information in the database. That was a so-called polling approach.
In this release we switched from polling to a push-based approach. Instead of
st2resulttracker periodically polling Mistral for workflow status, Mistral now notifies StackStorm of completion, using the
This approach allows for a better utilization of CPU by action runners services and Mistral. On average users should see long Mistral workflows complete 5-20% faster compared to older versions.
We believe the performance increases we have seen and measured should apply to most of our users, so we have enabled this behavior by default. If for some reason you want to revert back to the previous approach you can do that by setting the
mistral.enable_polling config option to
True and restart all ST2 services.
…ran about 20% faster, with more of the machine actually being utilized by st2actionrunner instances instead of dominated by st2resultstracker and st2api
Quote from Nick Maludy (Encore Technologies), a long time StackStorm user and contributor who has tested this change on their setup.
For more information, please refer to the Mistral Workflows Completion, Latency, and Performance section of the documentation.
For people who would like to dig deeper and are interested in the code changes, you can check those pull requests – https://github.com/StackStorm/st2/pull/4000, https://github.com/StackStorm/st2mistral/pull/35, https://github.com/StackStorm/st2/pull/4023.
We added a new feature which allows users to specify a git revision (tag/branch/commit hash) of a pack resource (action) to use for an execution.
This functionality is useful in many scenarios, including zero downtime pack deployments where you have deployed a new version of a pack to the system, but you want some of your executions to still use the old version of the pack content.
Right now this feature is supported by the local and Python runner. It only applies and works with packs which are git repositories (this is the default recommended way and true for all packs on StackStorm Exchange).
Internally this feature utilizes git worktree functionality and requires a git version >= 2.5 to be installed on the system (the latest stable git version is recommended).
The best way to demonstrate this functionality is using a pack which was built for purposes of demonstrating and testing it – https://github.com/StackStorm-Exchange/stackstorm-test-content-version.
This pack contains 3 different actions which sole purpose is to print out the current pack version. The pack itself contains 4 different versions/tags (v0.1.0, v0.2.0, v0.3.0, v0.4.0). In a standard StackStorm pack git repository layout each pack version should have a corresponding git tag.
By default, if no version if specified, the latest installed and checked out version is used. This is the same behavior as before:
To run a specific version, you provide content_version runner parameter. In this case we specified git tag v0.2.0 which matches the same pack version:
More information and limitations can be found in the documentation – Using a Specific Version of Pack Content When Running an Action.
In addition to those two new features, this release also includes many other improvements and bug-fixes.
To name a few:
For a full list of changes, please refer to the changelog.
As always, this release wouldn’t have been possible without our great open-source community and users.
Special thanks to Nick Maludy, Anthony Shaw, Ben Hohnke, Carlos, @djh2020, @mxmader, @sumkire, @SURAJTHEGREAT and others who have contributed to the release in one form or another.