⁠Chapter 14. Status — Here be dragons

Table of Contents

Most users never need to understand the contents of the status section and can be happy with the output from crm_mon.

However for those with a curious inclination, this section attempts to provide an overview of its contents.

⁠14.1. Node Status

In addition to the cluster’s configuration, the CIB holds an up-to-date representation of each cluster node in the status section.

⁠

Example 14.1. A bare-bones status entry for a healthy node cl-virt-1

  <node_state id="1" uname="cl-virt-1" in_ccm="true" crmd="online" crm-debug-origin="do_update_resource" join="member" expected="member">
   <transient_attributes id="1"/>
   <lrm id="1"/>
  </node_state>

Users are highly recommended not to modify any part of a node’s state directly. The cluster will periodically regenerate the entire section from authoritative sources, so any changes should be done with the tools appropriate to those sources.

⁠

Table 14.1. Authoritative Sources for State Information

CIB Object	Authoritative Source
`node_state`	pacemaker-controld
`transient_attributes`	pacemaker-attrd
`lrm`	pacemaker-execd

The fields used in the node_state objects are named as they are largely for historical reasons and are rooted in Pacemaker’s origins as the resource manager for the older Heartbeat project. They have remained unchanged to preserve compatibility with older versions.

⁠

Table 14.2. Node Status Fields

Field	Description
`id`	Unique identifier for the node. Corosync-based clusters use a numeric counter.
`uname`	The node’s name as known by the cluster
`in_ccm`	Is the node a member at the cluster communication layer? Allowed values: `true`, `false`.
`crmd`	Is the node a member at the pacemaker layer? Allowed values: `online`, `offline`.
`crm-debug-origin`	The name of the source function that made the most recent change (for debugging purposes).
`join`	Does the node participate in hosting resources? Allowed values: `down`, `pending`, `member`, `banned`.
`expected`	Expected value for `join`.

The cluster uses these fields to determine whether, at the node level, the node is healthy or is in a failed state and needs to be fenced.