Appendix D. Modifying and Enforcing Cluster Service Resource Actions
Actions are to a resource agent what method invocations are to an object in the object oriented approach to programming — a form of a contract between the provider of the functionality (resource agent) and its user (RGManager), technically posing as an interface (API). RGManager relies on resource agents recognizing a set of a few actions that are part of this contract. Actions can have properties with the respective defaults declared in the same way as a set of actions the particular agent supports; that is, in its metadata (themselves obtainable by means of the mandatory
meta-data action). You can override these defaults with explicit <action> specifications in the cluster.conf file:
- For the
startandstopactions, you may want to modify thetimeoutproperty. - For the
statusaction, you may want to modify thetimeout,interval, ordepthproperties. For information on thestatusaction and its properties, see Section D.1, “Modifying the Resource Status Check Interval”.
Note that the
timeout property for an action is enforced only if you explicitly configure timeout enforcement, as described in Section D.2, “Enforcing Resource Timeouts”.
For an example of how to configure the
cluster.conf file to modify a resource action parameter, see Section D.1, “Modifying the Resource Status Check Interval”.
Note
To fully comprehend the information in this appendix, you may require detailed understanding of resource agents and the cluster configuration file,
/etc/cluster/cluster.conf. For a comprehensive list and description of cluster.conf elements and attributes, see the cluster schema at /usr/share/cluster/cluster.rng, and the annotated schema at /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (for example /usr/share/doc/cman-3.0.12/cluster_conf.html).
D.1. Modifying the Resource Status Check Interval
RGManager checks the status of individual resources, not whole services. Every 10 seconds, RGManager scans the resource tree, looking for resources that have passed their "status check" interval.
Each resource agent specifies the amount of time between periodic status checks. Each resource utilizes these timeout values unless explicitly overridden in the
cluster.conf file using the special <action> tag:
<action name="status" depth="*" interval="10" />
This tag is a special child of the resource itself in the
cluster.conf file. For example, if you had a file system resource for which you wanted to override the status check interval you could specify the file system resource in the cluster.conf file as follows:
<fs name="test" device="/dev/sdb3">
<action name="status" depth="*" interval="10" />
<nfsexport...>
</nfsexport>
</fs>
Some agents provide multiple "depths" of checking. For example, a normal file system status check (depth 0) checks whether the file system is mounted in the correct place. A more intensive check is depth 10, which checks whether you can read a file from the file system. A status check of depth 20 checks whether you can write to the file system. In the example given here, the
depth is set to *, which indicates that these values should be used for all depths. The result is that the test file system is checked at the highest-defined depth provided by the resource-agent (in this case, 20) every 10 seconds.
