Say hello to StackStorm v2.7

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.

Improved Performance of Mistral Workflows

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 st2api service.

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.

StackStorm services CPU usage when using old polling approach. For higher resolution, click on the photo.

StackStorm services CPU usage when using new push (callback) approach. For higher resolution, click on the photo.

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 –,,

Ability to specify a git revision of a pack action to use for an execution

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

If you running Ubuntu 14.04 you can get the latest version of git from the official git ppa repository and if you use RedHat 6 / 7, you can use IUS repositories.

Example Usage

The best way to demonstrate this functionality is using a pack which was built for purposes of demonstrating and testing it –

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.

For people interested in the code changes, please see the following pull requests –,

Other Changes

In addition to those two new features, this release also includes many other improvements and bug-fixes.

To name a few:

  • `st2 execution tail` command now supports double nested workflows.
  • Fix Python runner actions and “Argument list too long” error when very large parameters are passed into the action.
  • All the runners are now fully standalone and re-distributable Python packages.
  • Updates to the Windows runner so the result object now matches result object from the local and remote runner. This change is partially backward incompatible, for more details, please refer to the Upgrade Notes.
  • Various internal code changes which will make supporting Python 3 in the future easier.

For a full list of changes, please refer to the changelog.

Try It Out

v2.7.1 packages are available in apt and yum repos. Follow the standard instructions to install this version, or upgrade following the General Upgrade Procedure. As always, backup first.

Thank You

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.