4.4. Resource Options

⁠4.4. Resource Options

Resources have two types of options: meta-attributes and instance attributes. Meta-attributes apply to any type of resource, while instance attributes are specific to each resource agent.

⁠4.4.1. Resource Meta-Attributes

Meta-attributes are used by the cluster to decide how a resource should behave and can be easily set using the --meta option of the crm_resource command.

⁠

Table 4.2. Meta-attributes of a Primitive Resource

Field	Default	Description
`priority`	0	If not all resources can be active, the cluster will stop lower priority resources in order to keep higher priority ones active.
`target-role`	Started	What state should the cluster attempt to keep this resource in? Allowed values: `Stopped:` Force the resource to be stopped `Started:` Allow the resource to be started (and in the case of promotable clone resources, promoted to master if appropriate) `Slave:` Allow the resource to be started, but only in Slave mode if the resource is promotable `Master:` Equivalent to `Started`
`is-managed`	TRUE	Is the cluster allowed to start and stop the resource? Allowed values: `true`, `false`
`maintenance`	FALSE	Similar to the `maintenance-mode` cluster option, but for a single resource. If true, the resource will not be started, stopped, or monitored on any node. This differs from `is-managed` in that monitors will not be run. Allowed values: `true`, `false`
`resource-stickiness`	1 for individual clone instances, 0 for all other resources	A score that will be added to the current node when a resource is already active. This allows running resources to stay where they are, even if they would be placed elsewhere if they were being started from a stopped state.
`requires`	`quorum` for resources with a `class` of `stonith`, otherwise `unfencing` if unfencing is active in the cluster, otherwise `fencing` if `stonith-enabled` is true, otherwise `quorum`	Conditions under which the resource can be started Allowed values: `nothing:` can always be started `quorum:` The cluster can only start this resource if a majority of the configured nodes are active `fencing:` The cluster can only start this resource if a majority of the configured nodes are active and any failed or unknown nodes have been fenced `unfencing:` The cluster can only start this resource if a majority of the configured nodes are active and any failed or unknown nodes have been fenced and only on nodes that have been unfenced
`migration-threshold`	INFINITY	How many failures may occur for this resource on a node, before this node is marked ineligible to host this resource. A value of 0 indicates that this feature is disabled (the node will never be marked ineligible); by constrast, the cluster treats INFINITY (the default) as a very large but finite number. This option has an effect only if the failed operation specifies `on-fail` as `restart` (the default), and additionally for failed `start` operations, if the cluster property `start-failure-is-fatal` is `false`.
`failure-timeout`	0	How many seconds to wait before acting as if the failure had not occurred, and potentially allowing the resource back to the node on which it failed. A value of 0 indicates that this feature is disabled.
`multiple-active`	stop_start	What should the cluster do if it ever finds the resource active on more than one node? Allowed values: `block:` mark the resource as unmanaged `stop_only:` stop all active instances and leave them that way `stop_start:` stop all active instances and start the resource in one location only
`allow-migrate`	TRUE for ocf:pacemaker:remote resources, FALSE otherwise	Whether the cluster should try to "live migrate" this resource when it needs to be moved (see Section 9.3.3, “Migrating Resources”)
`container-attribute-target`		Specific to bundle resources; see Section 10.3.7, “Bundle Node Attributes”
`remote-node`		The name of the Pacemaker Remote guest node this resource is associated with, if any. If specified, this both enables the resource as a guest node and defines the unique name used to identify the guest node. The guest must be configured to run the Pacemaker Remote daemon when it is started. `WARNING:` This value cannot overlap with any resource or node IDs.
`remote-port`	3121	If `remote-node` is specified, the port on the guest used for its Pacemaker Remote connection. The Pacemaker Remote daemon on the guest must be configured to listen on this port.
`remote-addr`	value of `remote-node`	If `remote-node` is specified, the IP address or hostname used to connect to the guest via Pacemaker Remote. The Pacemaker Remote daemon on the guest must be configured to accept connections on this address.
`remote-connect-timeout`	60s	If `remote-node` is specified, how long before a pending guest connection will time out.

As an example of setting resource options, if you performed the following commands on an LSB Email resource:

# crm_resource --meta --resource Email --set-parameter priority --parameter-value 100
# crm_resource -m -r Email -p multiple-active -v block

the resulting resource definition might be:

⁠

Example 4.3. An LSB resource with cluster options

<primitive id="Email" class="lsb" type="exim">
  <meta_attributes id="Email-meta_attributes">
    <nvpair id="Email-meta_attributes-priority" name="priority" value="100"/>
    <nvpair id="Email-meta_attributes-multiple-active" name="multiple-active" value="block"/>
  </meta_attributes>
</primitive>

In addition to the cluster-defined meta-attributes described above, you may also configure arbitrary meta-attributes of your own choosing. Most commonly, this would be done for use in rules. For example, an IT department might define a custom meta-attribute to indicate which company department each resource is intended for. To reduce the chance of name collisions with cluster-defined meta-attributes added in the future, it is recommended to use a unique, organization-specific prefix for such attributes.