April 22, 2022
By Amanda McGuinness of intive
Coming up in StackStorm 3.7.0 is a new feature that allows administrators of a StackStorm installation to “override” the default resource status that was specified by the pack owners.StackStorm 3.7.0 is currently going through release preparation, and will be released soon.
One of the benefits of StackStorm is the large variety of packs available on the
StackStorm Exchange. But sometimes, users may not want the default content status provided by the community packs. We’re introducing a new feature into StackStorm 3.7.0 to make this easier to manage.
The current problem and workarounds
A common example, is where you want to use the actions from a pack, but not the sensors. Prior to StackStorm 3.7 when a pack is installed the state of all the resources comes from its source, e.g. the status held in GitHub. If only some of the resources are required to be enabled, the administrator has the option of:
- disabling these manually (eg via CLI/API/UI calls), but this status change will be lost upon a reload or installation of new version
- making the status change in the resource files. This could be done manually on the filesystem, but would again be lost on a new install from git. Or alternatively, a fork of the community pack could be maintained just to change the status, requiring updates each time new features in the community pack are desired.
The new override feature
With StackStorm 3.7 there is a new feature that allows the StackStorm administrator to configure pack overrides following the same infrastructure-as-code approach that is the core to StackStorm. The administrator can create override files to override the status of the resource when the pack is loaded – either from reload or install/upgrade.
They can define this override behaviour at 3 levels of granularity (using as many or as few levels as they desire). These levels in the order they are applied are:
- global override – specify a default behaviour of that resource type, e.g. disable all sensors
- pack override – specify the default behaviour per resource type at a per pack level, e.g. disable all sensors for packA
- individual resource override – specify the status of an individual resource, e.g. disable an individual sensor
The status of resources of the following types can be overridden:
- sensors
- rules
- actions
- aliases
The ability to temporarily change the status via the enable/disable CLI/API/UI interfaces still exist and will change the status until the resource is reloaded or pack upgraded.
An example
The levels of override can be used in any combination. The following example will disable all sensors except for those in packA and a single sensor in packB. This is achieved with the following steps:
- Firstly, the creation of the /opt/stackstorm/overrides/_global.yaml file set to disable all sensors.
---
sensors:
defaults:
enabled: false
- Secondly, the creation of the /opt/stackstorm/overrides/packA.yaml to enable the sensors in packA.
--
sensors:
defaults:
enabled: true
- Thirdly, the creation of the /opt/stackstorm/overrides/packB.yaml to enable a single sensor sensorIWant in packB.
--
sensors:
exceptions:
sensorIWant:
enabled: true
-
Then run a st2ctl reload to reload the configuration, and only sensors in packA and packB.sensorIWant will be enabled. The sensors will stay in this state across any further reloads or pack upgrades/installs, but can have their status temporarily updated via the disable API/UI/CLI calls.
Further information
More information on the override feature, with examples of its use can be found on the
documentation page.
The override feature was an enhancement discussed for many years, and after collaborative discussion by the TSC was implemented by
Amanda McGuinness , from StackStorm partner
intive. We hope that the StackStorm community enjoys this new feature that will be available in the upcoming StackStorm 3.7.0 release. Keep an eye out on our
blog for the announcement of when StackStorm 3.7.0 is available.
Participation
As ever, we welcome contributions from our community – so if you’d like to implement a new feature in StackStorm please reach out to the StackStorm TSC and Slack Community, who will offer support and guidance, or reach out to a StackStorm partner.
We welcome and appreciate contributions of any kind (code, tests, documentation, examples, use cases, etc.). If you need help or get stuck at any point then at the Slack Community we will do our best to assist you.
