In this recipe, we will look into policies. We will learn how to create and use policies to react automatically to events that occur outside Orchestrator.
For this recipe, we need something that we can monitor for events. We have a look at policies with the recipes Working with SNMP and Working with AMQP in Chapter 10, Built-in Plugins.
In this example, we will monitor objects in the vCenter server.
We will create a simple policy that will monitor a VM by performing the following steps:
- In the Orchestrator Client, switch to the Run mode and click on Policies.
- Click on Create a new Policy (the icon that looks like a scroll with a plus sign).
- After you give the policy a name, you will find a new policy in the policy list. Right-click the policy you have created and select Edit (the pencil icon):
- In the General tab under Startup, choose whether the policy should be started with the Orchestrator service or not. This is used when Orchestrator is powered down and you want to start the policy with an Orchestrator server start.
- Priority regulates how multiple policies determine priorities about each other.
- The credentials under Startup user are used to run the policy:
- Switch to the Scripting tab.
- Click on the top element (scroll icon) and then select Add policy element (scroll down; you will see an icon with a plus sign).
- Select a policy element (choose VC:VirtualMachine) and click on OK. Then, select a VM that you would like to monitor (I selected a VM called OrchestratorVM which is just a plain VM, not the Orchestrator itself).
- Right-click on the new policy (called tag-0) and then Add trigger event. From the pop-up, select OnStateChanged. This trigger will monitor the VM for changes in its power state.
- Click on the OnStateChanged trigger and then select a workflow or write a script that is executed. I wrote the following script:
System.log("VM changed state");
- Click on Save and close.
- Now start the policy by clicking on the play button. Go to vCenter server and start or stop the VM you are monitoring. If you have used the same script as mine, you should see a message.
Policies are constant monitoring programs that check whether a monitored event has been triggered. The VMware documentation about policies is really nonexistent. You will find some more information regarding policies in the upcoming sections.
As a supplement to this recipe, have a look at the recipes Working with SNMP and Working with AMQP in Chapter 10, Built-in Plugins. In these recipes, we use policies.
When you configured the policy to start with the Orchestrator server, then the check box next to the policy shows a tick in it (see following figure):
Let's start by defining the difference between polices and policy templates. If you repeat the same recipe as described earlier, under the Policy Templates tab you will find that you won't be able to define which VM you would like to monitor. This is what templates are about; you define the raw layout, triggers, and script, and so on. If you then want to apply the template, you can choose Apply Policy (scroll down, you will see a green right arrow icon) from either the template in the Template tab or the Policy tab.
Triggers are implemented by plugins and can be used to build policies. There are three basic elements that can be added to policies:
|
Icon |
Name |
Function |
|
|
Policy Element |
This monitors an element such as a VM or SNMP device. |
|
|
Periodic Task |
This is a workflow or script that will be executed on a given timescale. |
|
|
Trigger |
This is a trigger that starts a script or workflow. |
Each element can have special triggers. A trigger can either start a workflow or run a script, but not both. In the following tables, you will find detailed information on which trigger is available with what element. The OnInit and OnExit triggers can be added to any element. The OnInit and OnExit triggers are actually quite important, for example, when you need to write a script that checks whether all conditions that the policy requires (such as whether an AMQP queue exists or a VM exists) are met:
|
Element |
Trigger element |
Threshold |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
N/A |
|
|
|
|
|
|
|
N/A |
|
|
|
N/A |
|
|
|
|
Here is an explanation of all triggers:
|
Trigger |
Meaning |
|
|
This is triggered when the policy is started. |
|
|
This is triggered when a policy is stopped. |
|
|
This is triggered when a periodic task is triggered. |
|
|
This is triggered when a new SNMP message is trapped. |
|
|
This is triggered when a new AMQP message is in the queue. |
|
|
This is triggered when the health of the object changes. |
|
|
This is triggered when a VM/host is not available for management; for example, VM is disconnected due to ESXi failure or a host is switched off. |
|
|
This is triggered when a host is entering/exiting the maintenance mode. |
|
|
This is triggered when the power state of a VM changes. |
|
|
This is triggered when the amount of console session towards a VM/host is below or above a set value. |
|
|
This is triggered when a CPU, memory, disk, or network is below or above a set value; all values are in percentages. |
The event variable is almost un-documented and any information is hard to find. The following are the known event properties and methods:
|
Variable |
Function |
|
|
Gets the date as a number. |
|
|
An object that contains the source of the event. |
|
|
Receives the SNMP source. |
|
|
Retrieves the SNMP message. |
|
|
Retrieves an AMQP message. |
See the recipes Working with SNMP and Working with AMQP in Chapter 10, Built-in Plugins.