The documentation you're currently reading is for version 2.4.1. 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, run:
st2 policy-type list.
Policy configuration files should be stored in the
policies folder in their respective 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 delayed until the number of concurrent executions of a particular actions falls below the threshold. As an alternative, users can specify that new executions are canceled, rather than delayed.
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
policy_type are the fully qualified name for the action and policy
type respectively. The
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 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,
we can limit the number of concurrent
demo.my_remote_action actions running for a given remote
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.
If you have installed a coordination service in your network, you need to configure BWC to
connect to that backend service. This is done 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).