The TransitionGraph overview

The TransitionGraph is computed by the PolicyEngine[1] and then typically provided as input to the TransitionEngine[2]. It describes the actions and their dependencies necessary to go from the CurrentClusterState[3] to the TargetClusterState[4], in which hopefully all resources are provided by the cluster again.

The graph is divided into synapses, which need a given set of inputs to fire. The inputs are events in the cluster we are waiting on, and the actions are the actions which are started when all inputs are satisfied.

Thus, the TransitionGraph provides the TransitionEngine[2] with enough information to parallelize operations for performance.

The formal syntax is described in the crm/crm-1.0.dtd file, but here are some more comments on how this is supposed to work:

Inputs

Any event in the cluster - a resource changing state, a node leaving or joining, a CRM[5] event such as a CRM parting or leaving, or even a pseudo-event generated somewhere else in the graph - can be waited on.

Multiple inputs can be associated with one synapse, so you can chose to only trigger your actions if for example several other resources were started successfully already.

Note that you cannot only wait for successful operations, but also on failures.

Actions

A synapse can have multiple actions associated with it.

Basically, all actions which can be initiated by the ClusterResourceManager[6] are possible, such as instructing a LocalResourceManager[7] to perform an operation via a ResourceAgent[8] (starting, stopping, fencing...), or a CRM event which instructs a ClusterResourceManager[6] to shutdown, trigger an election etc. Additionally, you can send a pseudo event, which is just good for explicitly linking synapses.

---

This information provided courtesy of the Linux-HA project at http://linux-ha.org/