Groups
Get the latest docs
You are looking at documentation for an older release. Not what you want? Go to the current release documentation.groups enables you to configuring shared behavior for different sets ofnode_templates.
Declaration
Within each group, the policies section is a dictionary in which each item in the dictionary represents a policy.
Within each policy, the triggers section is a dictionary in which each item in the dictionary represents a trigger.
groups:
group1:
members: ...
policies:
policy1:
type: ...
properties:
...
triggers:
trigger1:
type: ...
parameters: ...
trigger2:
...
policy2:
...
group2:
...
Schema
| Keyname | Required | Type | Description |
|---|---|---|---|
| members | yes | list | A list of group members. Members are node template names or other group names. |
| policies | no | dict | A dictionary of policies. |
Note
When using groups as scaling groups in combination with top-level policies, you can define nested groups in which group members may be other groups.
See Policies.
Policy Schema
| Keyname | Required | Type | Description |
|---|---|---|---|
| type | yes | string | Policy type. |
| properties | no | dict | Optional properties for configuring the policy. |
| triggers | yes | dict | A dictionary of triggers. |
Trigger Schema
| Keyname | Required | Type | Description |
|---|---|---|---|
| type | yes | string | Trigger type. |
| parameters | no | dict | Optional parameters to be passed to the trigger. |
Inside the trigger’s parameters section, { get_property: [SELF, property_name] } can be used to access properties of the event that caused the trigger to be processed. For example, a policy may add contextual data to an event, such as a node instance ID or the CPU average in the last five minutes, before processing its triggers. An execute_workflow trigger, for example, may pass these properties to the workflow it executes.
Example
For an example on how to use policies, see Using Policies.