November 16, 2015
by Tomaz Muraus
Slightly more than 2 weeks after the StackStorm v1.1.0 release we are happy to announce that we have just released StackStorm v1.1.1.
As you can guess from the version identifier (since v1.1.0 release we are following semantic versioning), this is minor release which means there are no breaking or backward incompatible changes and the release mostly includes smaller improvements and bug fixes.
Before we dive into v1.1.1, here is a quick recap of new features which were released in StackStorm v1.1.0.
New (graphical) installer
StackStorm v1.1 introduced a new graphical based installer which allows you to easily install and configure StackStorm on a single server.
First page of the installer where hostname SSL certificate and enterprise license key is configured.
In addition to the graphical mode, installer also allows user to providers “answers” file (YAML file with configuration options) and run in unattended mode.
The goal of the installer is to reduce the barrier to entry and make it easier and faster to get up and running with StackStorm.
Enterprise Edition with RBAC, Flow, LDAP authentication backend and more
In addition to many other new features and improvements, StackStorm v1.1 was also the first release which brings our Enterprise Edition.
The StackStorm v1.1 Enterprise Edition builds on top of the community edition which is fully free and open source and adds some additional features which come handy especially in large enterprise environments.
Flow
Flow is a one of a kind graphical workflow editor which fully embraces and integrates with the infrastructure as code approach.
Flow with an opened disk auto remediation workflow.
The goal of flow is to make it easier for users to build, visualize and share workflows. This comes especially handy for complex workflows with many tasks and transitions.
Flow also differentiates itself from legacy workflow editors by running in the browser (no need to install resource hungry Java applications) and by being built on open-source technologies such as d3 and react.
In addition to that, Flow fully embraces an infrastructure as code approach – all the changes you make in the graphical editor are immediately visible in the right pane which contains “source” code (easy to read YAML) for that workflow. Embracing infrastructure as code means that workflows are the same as any other source code or configuration files – you can version control them, review them, etc.
The right pane with source code is also editable which means you can quickly switch between “drag and drop” and text based editing.
Role Based Access Control (RBAC)
The Enterprise Edition also comes with Role Based Access Control (RBAC) which allows you to restrict user access to particular operations.
An error which is displayed when a user doesn’t have a permission to run (execute) an action (in this case this is “core.local” action).
RBAC is an essential feature for large teams and organizations where you have many people working on different projects. RBAC allows you to organize permissions into roles and assign those roles to the StackStorm users.
My favorite example of this is a user who has a powerful automation called “bootstrap datacenter” – for obvious reasons, they’d rather not have everyone who has access to StackStorm able to run this automation.
Another example is limiting which actions StackStorm users can view and run . You can lock parameters for a particular action (e.g. if you have “create_vm” action you could limit “region” parameter to a particular set of approved regions).
That’s a quick recap. For a deeper dive and more information about v1.1.0 and the Enterprise Edition, please check the following post – StackStorm v1 is out.
And now back to the shiny new v1.1.1.
Improved CLI experience
We have optimized the speed of the CLI and now performing operations such as listing executions (st2 execution list) and retrieving particular execution details (st2 execution get) is much faster. This is especially noticeable for users with a lot of executions which contain large results.
In our build server case where we have many executions with large results, running time of “st2 execution list” went from 8 seconds down to 0.5 seconds.
Another improvement we made to the st2 execution list is displaying elapsed / running time for all the executions which are currently in the “running” state.
Output of “st2 execution list -n5” command.
This makes it easier to see, at a glance, how long a particular action has been running. This is also useful for helping you identify outliers and actions which are potentially stuck and will result in a timeout.
Improved action-chain workflow validation
We’ve made some improvements to the action-chain workflows so some validation such as task existence, etc. is done immediately when the workflow runs. Previously, some of that validation happened only when the task was about to run. This means that in cases where you have many long running tasks it could take many minutes to identify some common errors such as a typo in the referenced task name.
Detecting common validation errors as early as possible is very important since it speeds up the whole “develop-test/run” feedback loop. Imagine if you need to wait for 10 minutes for tasks to finish to notice that you have made a typo in one of the referenced tasks – that’s not very pleasant and you lose motivation and context.
It’s also worth pointing out that because of the dynamic nature of the workflows (e.g. using jinja expressions in the task names, etc.) some validation can only be performed during actual run-time.
That’s it for the highlights. You can find the whole list of changes here. We encourage you to go try it out and join us at our Slack community channel (or #stackstorm on freenode) if you are an IRC person) where you can leave your feedback and chat with other stormers and StackStorm users.