Chapter 3. Cluster-Wide Configuration

Table of Contents

3.1. CIB Properties

Certain settings are defined by CIB properties (that is, attributes of the cib tag) rather than with the rest of the cluster configuration in the configuration section.

The reason is simply a matter of parsing. These options are used by the configuration database which is, by design, mostly ignorant of the content it holds. So the decision was made to place them in an easy-to-find location.

Table 3.1. CIB Properties

Field	Description
`admin_epoch`	When a node joins the cluster, the cluster performs a check to see which node has the best configuration. It asks the node with the highest (`admin_epoch`, `epoch`, `num_updates`) tuple to replace the configuration on all the nodes — which makes setting them, and setting them correctly, very important. `admin_epoch` is never modified by the cluster; you can use this to make the configurations on any inactive nodes obsolete. Never set this value to zero. In such cases, the cluster cannot tell the difference between your configuration and the "empty" one used when nothing is found on disk.
`epoch`	The cluster increments this every time the configuration is updated (usually by the administrator).
`num_updates`	The cluster increments this every time the configuration or status is updated (usually by the cluster) and resets it to 0 when epoch changes.
`validate-with`	Determines the type of XML validation that will be done on the configuration. If set to `none`, the cluster will not verify that updates conform to the DTD (nor reject ones that don’t). This option can be useful when operating a mixed-version cluster during an upgrade.
`cib-last-written`	Indicates when the configuration was last written to disk. Maintained by the cluster; for informational purposes only.
`have-quorum`	Indicates if the cluster has quorum. If false, this may mean that the cluster cannot start resources or fence other nodes (see `no-quorum-policy` below). Maintained by the cluster.
`dc-uuid`	Indicates which cluster node is the current leader. Used by the cluster when placing resources and determining the order of some events. Maintained by the cluster.

3.1.1. Working with CIB Properties

Although these fields can be written to by the user, in most cases the cluster will overwrite any values specified by the user with the "correct" ones.

To change the ones that can be specified by the user, for example admin_epoch, one should use:

# cibadmin --modify --xml-text '<cib admin_epoch="42"/>'

A complete set of CIB properties will look something like this:

Example 3.1. Attributes set for a cib object

<cib crm_feature_set="3.0.7" validate-with="pacemaker-1.2"
   admin_epoch="42" epoch="116" num_updates="1"
   cib-last-written="Mon Jan 12 15:46:39 2015" update-origin="rhel7-1"
   update-client="crm_attribute" have-quorum="1" dc-uuid="1">