5.5. Resource Operations

Operations are actions the cluster can perform on a resource by calling the resource agent. Resource agents must support certain common operations such as start, stop and monitor, and may implement any others.

Some operations are generated by the cluster itself, for example, stopping and starting resources as needed.

You can configure operations in the cluster configuration. As an example, by default the cluster will not ensure your resources stay healthy once they are started. ^[14] To instruct the cluster to do this, you need to add a monitor operation to the resource’s definition.

Example 5.6. An OCF resource with a recurring health check

<primitive id="Public-IP" class="ocf" type="IPaddr" provider="heartbeat">
  <operations>
     <op id="public-ip-check" name="monitor" interval="60s"/>
  </operations>
  <instance_attributes id="params-public-ip">
     <nvpair id="public-ip-addr" name="ip" value="192.0.2.2"/>
  </instance_attributes>
</primitive>

Table 5.3. Properties of an Operation

Field	Default	Description
`id`		A unique name for the operation.
`name`		The action to perform. This can be any action supported by the agent; common values include `monitor`, `start`, and `stop`.
`interval`	0	How frequently (in seconds) to perform the operation. A value of 0 means never. A positive value defines a recurring action, which is typically used with monitor.
`timeout`		How long to wait before declaring the action has failed
`on-fail`	restart (except for stop operations, which default to fence when STONITH is enabled and block otherwise)	The action to take if this action ever fails. Allowed values: `ignore:` Pretend the resource did not fail. `block:` Don’t perform any further operations on the resource. `stop:` Stop the resource and do not start it elsewhere. `restart:` Stop the resource and start it again (possibly on a different node). `fence:` STONITH the node on which the resource failed. `standby:` Move all resources away from the node on which the resource failed.
`enabled`	TRUE	If `false`, ignore this operation definition. This is typically used to pause a particular recurring monitor operation; for instance, it can complement the respective resource being unmanaged (`is-managed=false`), as this alone will not block any configured monitoring. Disabling the operation does not suppress all actions of the given type. Allowed values: `true`, `false`.
`record-pending`	FALSE	If `true`, the intention to perform the operation is recorded so that GUIs and CLI tools can indicate that an operation is in progress. This is best set as an operation default (see next section). Allowed values: `true`, `false`.
`role`		Run the operation only on node(s) that the cluster thinks should be in the specified role. This only makes sense for recurring monitor operations. Allowed (case-sensitive) values: `Stopped`, `Started`, and in the case of multi-state resources, `Slave` and `Master`.

5.5.1. Monitoring Resources for Failure

When Pacemaker first starts a resource, it runs one-time monitor operations (referred to as probes) to ensure the resource is running where it’s supposed to be, and not running where it’s not supposed to be. (This behavior can be affected by the resource-discovery location constraint property.)

Other than those initial probes, Pacemaker will not (by default) check that the resource continues to stay healthy. As in the example above, you must configure monitor operations explicitly to perform these checks.

By default, a monitor operation will ensure that the resource is running where it is supposed to. The target-role property can be used for further checking.

For example, if a resource has one monitor operation with interval=10 role=Started and a second monitor operation with interval=11 role=Stopped, the cluster will run the first monitor on any nodes it thinks should be running the resource, and the second monitor on any nodes that it thinks should not be running the resource (for the truly paranoid, who want to know when an administrator manually starts a service by mistake).

^[14] Currently, anyway. Automatic monitoring operations may be added in a future version of Pacemaker.