The documentation you're currently reading is for version 2.3.2. Click here to view documentation for the latest stable version.
Policies allows users to enforce different rules regarding action executions.
To list the types of policy that are available for configuration, run the command
st2 policy-type list.
Policy configuration files are expected to be located under the
policies folder in related
packs, similar to actions and rules. Policies can be loaded into BWC via
st2ctl reload --register-policies. Once policies are loaded into BWC, run the command
st2 policy list to view the list of policies in effect.
The concurrency policy enforces the number of executions that can run simultaneously for a specified action.
By default when a threshold is reached, action execution is postponed until a number concurrent executions of a particular actions falls below the threshold. As an alternative, user can also specify for execution to be canceled instead of it being delayed / postponed.
There are two forms of concurrency policy:
action.concurrency policy limits the concurrent executions for the action. The following
is an example of a policy file with concurrency defined for
demo.my_action. Please note that
the resource_ref and policy_type are the fully qualified name for the action and policy type
threshold parameter defines how many concurrent instances are allowed. In
this example, no more than 10 instances of
demo.my_action can be run simultaneously. Any
execution requests above this threshold will be postponed.
name: my_action.concurrency description: Limits the concurrent executions for my action. enabled: true resource_ref: demo.my_action policy_type: action.concurrency parameters: action: delay threshold: 10
If you want further actions to be canceled instead of delayed,
action attribute should be
cancel as shown below.
name: my_action.concurrency description: Limits the concurrent executions for my action. enabled: true resource_ref: demo.my_action policy_type: action.concurrency parameters: action: cancel threshold: 1
action.concurrency.attr policy limits the executions for the action by input arguments.
demo.my_remote_action has an input argument defined called
hostname. This is the
name of the host where the remote command or script runs. By using the policy type
action.concurrency.attr and specifying
hostname as one of the attributes in the policy,
only a number of
demo.my_remote_action up to the defined threshold can run simultaneously on a
given remote host.
name: my_remote_action.concurrency description: Limits the concurrent executions for my action. enabled: true resource_ref: demo.my_remote_action policy_type: action.concurrency.attr parameters: action: delay threshold: 10 attributes: - hostname
The concurrency policy type is not enabled by default and requires a backend coordination service such as ZooKeeper or Redis to work.
Let’s assume ZooKeeper or Redis is running on the same network where BWC is installed. To enable
the concurrency policy type in BWC, provide the url to connect to the backend service in the
coordination section of
The following are examples for ZooKeeper and Redis:
[coordination] url = kazoo://username:password@host:port
[coordination] url = redis://:password@host:port
Other supported coordination backends include:
- file (for testing when all the services are running on a single host)
For the full list of the supported backends and how to configure them, please visit OpenStack tooz documentation.
Some of these coordination backends also require corresponding client libraries to be installed in BWC virtualenv. We do not ship these libraries by default. As an example, to install the client library in BWC virtualenv, run:
sudo su # Example when using redis backend /opt/stackstorm/st2/bin/pip install redis # Example when using consul backend /opt/stackstorm/st2/bin/pip install consul
Retry policy (
action.retry) allows you to automatically retry (re-run) an action when a
particular failure condition is met. Right now we support retrying actions which have failed or
The example below shows how to automatically retry the
core.http action up to two times if it
--- name: http.retry description: Retry core.http action on timeout. enabled: true resource_ref: core.http policy_type: action.retry parameters: retry_on: timeout max_retry_count: 2 delay: 2
Keep in mind that retrying an execution results in a new execution which shares all the attributes from the retried execution (parameters, context, etc).