diff --git a/doc/sphinx/Pacemaker_Explained/local-options.rst b/doc/sphinx/Pacemaker_Explained/local-options.rst
index d50d942e6c..7794873b52 100644
--- a/doc/sphinx/Pacemaker_Explained/local-options.rst
+++ b/doc/sphinx/Pacemaker_Explained/local-options.rst
@@ -1,734 +1,741 @@
Host-Local Configuration
------------------------
.. index::
pair: XML element; configuration
.. note:: Directory and file paths below may differ on your system depending on
your Pacemaker build settings. Check your Pacemaker configuration
file to find the correct paths.
Configuration Value Types
#########################
Throughout this document, configuration values will be designated as having one
of the following types:
.. list-table:: **Configuration Value Types**
:class: longtable
:widths: 1 3
:header-rows: 1
* - Type
- Description
* - .. _boolean:
.. index::
pair: type; boolean
boolean
- Case-insensitive text value where ``1``, ``yes``, ``y``, ``on``,
and ``true`` evaluate as true and ``0``, ``no``, ``n``, ``off``,
``false``, and unset evaluate as false
* - .. _date_time:
.. index::
pair: type; date/time
date/time
- Textual timestamp like ``Sat Dec 21 11:47:45 2013``
* - .. _duration:
.. index::
pair: type; duration
duration
- A time duration, specified either like a :ref:`timeout <timeout>` or an
`ISO 8601 duration <https://en.wikipedia.org/wiki/ISO_8601#Durations>`_.
A duration may be up to approximately 49 days but is intended for much
smaller time periods.
* - .. _enumeration:
.. index::
pair: type; enumeration
enumeration
- Text that must be one of a set of defined values (which will be listed
in the description)
* - .. _epoch_time:
.. index::
pair: type; epoch_time
epoch_time
- Time as the integer number of seconds since the Unix epoch,
``1970-01-01 00:00:00 +0000 (UTC)``.
* - .. _id:
.. index::
pair: type; id
id
- A text string starting with a letter or underbar, followed by any
combination of letters, numbers, dashes, dots, and/or underbars; when
used for a property named ``id``, the string must be unique across all
``id`` properties in the CIB
* - .. _integer:
.. index::
pair: type; integer
integer
- 32-bit signed integer value (-2,147,483,648 to 2,147,483,647)
+ * - .. _iso8601:
+
+ .. index::
+ pair: type; iso8601
+
+ ISO 8601
+ - An `ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601>`_ date/time.
* - .. _nonnegative_integer:
.. index::
pair: type; nonnegative integer
nonnegative integer
- 32-bit nonnegative integer value (0 to 2,147,483,647)
* - .. _percentage:
.. index::
pair: type; percentage
percentage
- Floating-point number followed by an optional percent sign ('%')
* - .. _port:
.. index::
pair: type; port
port
- Integer TCP port number (0 to 65535)
* - .. _score:
.. index::
pair: type; score
score
- A Pacemaker score can be an integer between -1,000,000 and 1,000,000, or
a string alias: ``INFINITY`` or ``+INFINITY`` is equivalent to
1,000,000, ``-INFINITY`` is equivalent to -1,000,000, and ``red``,
``yellow``, and ``green`` are equivalent to integers as described in
:ref:`node-health`.
* - .. _text:
.. index::
pair: type; text
text
- A text string
* - .. _timeout:
.. index::
pair: type; timeout
timeout
- A time duration, specified as a bare number (in which case it is
considered to be in seconds) or a number with a unit (``ms`` or ``msec``
for milliseconds, ``us`` or ``usec`` for microseconds, ``s`` or ``sec``
for seconds, ``m`` or ``min`` for minutes, ``h`` or ``hr`` for hours)
optionally with whitespace before and/or after the number.
* - .. _version:
.. index::
pair: type; version
version
- Version number (any combination of alphanumeric characters, dots, and
dashes, starting with a number).
Scores
______
Scores are integral to how Pacemaker works. Practically everything from moving
a resource to deciding which resource to stop in a degraded cluster is achieved
by manipulating scores in some way.
Scores are calculated per resource and node. Any node with a negative score for
a resource can't run that resource. The cluster places a resource on the node
with the highest score for it.
Score addition and subtraction follow these rules:
* Any value (including ``INFINITY``) - ``INFINITY`` = ``-INFINITY``
* ``INFINITY`` + any value other than ``-INFINITY`` = ``INFINITY``
.. note::
What if you want to use a score higher than 1,000,000? Typically this possibility
arises when someone wants to base the score on some external metric that might
go above 1,000,000.
The short answer is you can't.
The long answer is it is sometimes possible work around this limitation
creatively. You may be able to set the score to some computed value based on
the external metric rather than use the metric directly. For nodes, you can
store the metric as a node attribute, and query the attribute when computing
the score (possibly as part of a custom resource agent).
Local Options
#############
Pacemaker supports several host-local configuration options. These options can
be configured on each node in the main Pacemaker configuration file
(|PCMK_CONFIG_FILE|) in the format ``<NAME>="<VALUE>"``. They work by setting
environment variables when Pacemaker daemons start up.
.. list-table:: **Local Options**
:class: longtable
:widths: 2 2 2 5
:header-rows: 1
* - Name
- Type
- Default
- Description
* - .. _cib_pam_service:
.. index::
pair: node option; CIB_pam_service
CIB_pam_service
- :ref:`text <text>`
- login
- PAM service to use for remote CIB client authentication (passed to
``pam_start``).
* - .. _pcmk_logfacility:
.. index::
pair: node option; PCMK_logfacility
PCMK_logfacility
- :ref:`enumeration <enumeration>`
- daemon
- Enable logging via the system log or journal, using the specified log
facility. Messages sent here are of value to all Pacemaker
administrators. This can be disabled using ``none``, but that is not
recommended. Allowed values:
* ``none``
* ``daemon``
* ``user``
* ``local0``
* ``local1``
* ``local2``
* ``local3``
* ``local4``
* ``local5``
* ``local6``
* ``local7``
* - .. _pcmk_logpriority:
.. index::
pair: node option; PCMK_logpriority
PCMK_logpriority
- :ref:`enumeration <enumeration>`
- notice
- Unless system logging is disabled using ``PCMK_logfacility=none``,
messages of the specified log severity and higher will be sent to the
system log. The default is appropriate for most installations. Allowed
values:
* ``emerg``
* ``alert``
* ``crit``
* ``error``
* ``warning``
* ``notice``
* ``info``
* ``debug``
* - .. _pcmk_logfile:
.. index::
pair: node option; PCMK_logfile
PCMK_logfile
- :ref:`text <text>`
- |PCMK_LOG_FILE|
- Unless set to ``none``, more detailed log messages will be sent to the
specified file (in addition to the system log, if enabled). These
messages may have extended information, and will include messages of info
severity. This log is of more use to developers and advanced system
administrators, and when reporting problems. Note: The default is
|PCMK_CONTAINER_LOG_FILE| (inside the container) for bundled container
nodes; this would typically be mapped to a different path on the host
running the container.
* - .. _pcmk_logfile_mode:
.. index::
pair: node option; PCMK_logfile_mode
PCMK_logfile_mode
- :ref:`text <text>`
- 0660
- Pacemaker will set the permissions on the detail log to this value (see
``chmod(1)``).
* - .. _pcmk_debug:
.. index::
pair: node option; PCMK_debug
PCMK_debug
- :ref:`enumeration <enumeration>`
- no
- Whether to send debug severity messages to the detail log. This may be
set for all subsystems (``yes`` or ``no``) or for specific (comma-
separated) subsystems. Allowed subsystems are:
* ``pacemakerd``
* ``pacemaker-attrd``
* ``pacemaker-based``
* ``pacemaker-controld``
* ``pacemaker-execd``
* ``pacemaker-fenced``
* ``pacemaker-schedulerd``
Example: ``PCMK_debug="pacemakerd,pacemaker-execd"``
* - .. _pcmk_stderr:
.. index::
pair: node option; PCMK_stderr
PCMK_stderr
- :ref:`boolean <boolean>`
- no
- *Advanced Use Only:* Whether to send daemon log messages to stderr. This
would be useful only during troubleshooting, when starting Pacemaker
manually on the command line.
Setting this option in the configuration file is pointless, since the
file is not read when starting Pacemaker manually. However, it can be set
directly as an environment variable on the command line.
* - .. _pcmk_trace_functions:
.. index::
pair: node option; PCMK_trace_functions
PCMK_trace_functions
- :ref:`text <text>`
-
- *Advanced Use Only:* Send debug and trace severity messages from these
(comma-separated) source code functions to the detail log.
Example:
``PCMK_trace_functions="func1,func2"``
* - .. _pcmk_trace_files:
.. index::
pair: node option; PCMK_trace_files
PCMK_trace_files
- :ref:`text <text>`
-
- *Advanced Use Only:* Send debug and trace severity messages from all
functions in these (comma-separated) source file names to the detail log.
Example: ``PCMK_trace_files="file1.c,file2.c"``
* - .. _pcmk_trace_formats:
.. index::
pair: node option; PCMK_trace_formats
PCMK_trace_formats
- :ref:`text <text>`
-
- *Advanced Use Only:* Send trace severity messages that are generated by
these (comma-separated) format strings in the source code to the detail
log.
Example: ``PCMK_trace_formats="Error: %s (%d)"``
* - .. _pcmk_trace_tags:
.. index::
pair: node option; PCMK_trace_tags
PCMK_trace_tags
- :ref:`text <text>`
-
- *Advanced Use Only:* Send debug and trace severity messages related to
these (comma-separated) resource IDs to the detail log.
Example: ``PCMK_trace_tags="client-ip,dbfs"``
* - .. _pcmk_blackbox:
.. index::
pair: node option; PCMK_blackbox
PCMK_blackbox
- :ref:`enumeration <enumeration>`
- no
- *Advanced Use Only:* Enable blackbox logging globally (``yes`` or ``no``)
or by subsystem. A blackbox contains a rolling buffer of all logs (of all
severities). Blackboxes are stored under |CRM_BLACKBOX_DIR| by default,
by default, and their contents can be viewed using the ``qb-blackbox(8)``
command.
The blackbox recorder can be enabled at start using this variable, or at
runtime by sending a Pacemaker subsystem daemon process a ``SIGUSR1`` or
``SIGTRAP`` signal, and disabled by sending ``SIGUSR2`` (see
``kill(1)``). The blackbox will be written after a crash, assertion
failure, or ``SIGTRAP`` signal.
See :ref:`PCMK_debug <pcmk_debug>` for allowed subsystems.
Example:
``PCMK_blackbox="pacemakerd,pacemaker-execd"``
* - .. _pcmk_trace_blackbox:
.. index::
pair: node option; PCMK_trace_blackbox
PCMK_trace_blackbox
- :ref:`enumeration <enumeration>`
-
- *Advanced Use Only:* Write a blackbox whenever the message at the
specified function and line is logged. Multiple entries may be comma-
separated.
Example: ``PCMK_trace_blackbox="remote.c:144,remote.c:149"``
* - .. _pcmk_node_start_state:
.. index::
pair: node option; PCMK_node_start_state
PCMK_node_start_state
- :ref:`enumeration <enumeration>`
- default
- By default, the local host will join the cluster in an online or standby
state when Pacemaker first starts depending on whether it was previously
put into standby mode. If this variable is set to ``standby`` or
``online``, it will force the local host to join in the specified state.
* - .. _pcmk_node_action_limit:
.. index::
pair: node option; PCMK_node_action_limit
PCMK_node_action_limit
- :ref:`nonnegative integer <nonnegative_integer>`
-
- Specify the maximum number of jobs that can be scheduled on this node. If
set, this overrides the :ref:`node-action-limit <node_action_limit>`
cluster option on this node.
* - .. _pcmk_shutdown_delay:
.. index::
pair: node option; PCMK_shutdown_delay
PCMK_shutdown_delay
- :ref:`timeout <timeout>`
-
- Specify a delay before shutting down ``pacemakerd`` after shutting down
all other Pacemaker daemons.
* - .. _pcmk_fail_fast:
.. index::
pair: node option; PCMK_fail_fast
PCMK_fail_fast
- :ref:`boolean <boolean>`
- no
- By default, if a Pacemaker subsystem crashes, the main ``pacemakerd``
process will attempt to restart it. If this variable is set to ``yes``,
``pacemakerd`` will panic the local host instead.
* - .. _pcmk_panic_action:
.. index::
pair: node option; PCMK_panic_action
PCMK_panic_action
- :ref:`enumeration <enumeration>`
- reboot
- Pacemaker will panic the local host under certain conditions. By default,
this means rebooting the host. This variable can change that behavior: if
``crash``, trigger a kernel crash (useful if you want a kernel dump to
investigate); if ``sync-reboot`` or ``sync-crash``, synchronize
filesystems before rebooting the host or triggering a kernel crash. The
sync values are more likely to preserve log messages, but with the risk
that the host may be left active if the synchronization hangs.
* - .. _pcmk_authkey_location:
.. index::
pair: node option; PCMK_authkey_location
PCMK_authkey_location
- :ref:`text <text>`
- |PCMK_AUTHKEY_FILE|
- Use the contents of this file as the authorization key to use with
Pacemaker Remote connections. This file must be readable by Pacemaker
daemons (that is, it must allow read permissions to either the
|CRM_DAEMON_USER| user or the |CRM_DAEMON_GROUP| group), and its contents
must be identical on all nodes.
* - .. _pcmk_remote_address:
.. index::
pair: node option; PCMK_remote_address
PCMK_remote_address
- :ref:`text <text>`
-
- By default, if the Pacemaker Remote service is run on the local node, it
will listen for connections on all IP addresses. This may be set to one
address to listen on instead, as a resolvable hostname or as a numeric
IPv4 or IPv6 address. When resolving names or listening on all addresses,
IPv6 will be preferred if available. When listening on an IPv6 address,
IPv4 clients will be supported via IPv4-mapped IPv6 addresses.
Example: ``PCMK_remote_address="192.0.2.1"``
* - .. _pcmk_remote_port:
.. index::
pair: node option; PCMK_remote_port
PCMK_remote_port
- :ref:`port <port>`
- 3121
- Use this TCP port number for Pacemaker Remote node connections. This
value must be the same on all nodes.
* - .. _pcmk_remote_pid1:
.. index::
pair: node option; PCMK_remote_pid1
PCMK_remote_pid1
- :ref:`enumeration <enumeration>`
- default
- *Advanced Use Only:* When a bundle resource's ``run-command`` option is
left to default, Pacemaker Remote runs as PID 1 in the bundle's
containers. When it does so, it loads environment variables from the
container's |PCMK_INIT_ENV_FILE| and performs the PID 1 responsibility of
reaping dead subprocesses.
This option controls whether those actions are performed when Pacemaker
Remote is not running as PID 1. It is intended primarily for developer
testing but can be useful when ``run-command`` is set to a separate,
custom PID 1 process that launches Pacemaker Remote.
* ``full``: Pacemaker Remote loads environment variables from
|PCMK_INIT_ENV_FILE| and reaps dead subprocesses.
* ``vars``: Pacemaker Remote loads environment variables from
|PCMK_INIT_ENV_FILE| but does not reap dead subprocesses.
* ``default``: Pacemaker Remote performs neither action.
If Pacemaker Remote is running as PID 1, this option is ignored, and the
behavior is the same as for ``full``.
* - .. _pcmk_tls_priorities:
.. index::
pair: node option; PCMK_tls_priorities
PCMK_tls_priorities
- :ref:`text <text>`
- |PCMK_GNUTLS_PRIORITIES|
- *Advanced Use Only:* These GnuTLS cipher priorities will be used for TLS
connections (whether for Pacemaker Remote connections or remote CIB
access, when enabled). See:
https://gnutls.org/manual/html_node/Priority-Strings.html
Pacemaker will append ``":+ANON-DH"`` for remote CIB access and
``":+DHE-PSK:+PSK"`` for Pacemaker Remote connections, as they are
required for the respective functionality.
Example:
``PCMK_tls_priorities="SECURE128:+SECURE192"``
* - .. _pcmk_dh_min_bits:
.. index::
pair: node option; PCMK_dh_min_bits
PCMK_dh_min_bits
- :ref:`nonnegative integer <nonnegative_integer>`
- 0 (no minimum)
- *Advanced Use Only:* Set a lower bound on the bit length of the prime
number generated for Diffie-Hellman parameters needed by TLS connections.
The default is no minimum.
The server (Pacemaker Remote daemon, or CIB manager configured to accept
remote clients) will use this value to provide a floor for the value
recommended by the GnuTLS library. The library will only accept a limited
number of specific values, which vary by library version, so setting
these is recommended only when required for compatibility with specific
client versions.
Clients (connecting cluster nodes or remote CIB commands) will require
that the server use a prime of at least this size. This is recommended
only when the value must be lowered in order for the client's GnuTLS
library to accept a connection to an older server.
* - .. _pcmk_dh_max_bits:
.. index::
pair: node option; PCMK_dh_max_bits
PCMK_dh_max_bits
- :ref:`nonnegative integer <nonnegative_integer>`
- 0 (no maximum)
- *Advanced Use Only:* Set an upper bound on the bit length of the prime
number generated for Diffie-Hellman parameters needed by TLS connections.
The default is no maximum.
The server (Pacemaker Remote daemon, or CIB manager configured to accept
remote clients) will use this value to provide a ceiling for the value
recommended by the GnuTLS library. The library will only accept a limited
number of specific values, which vary by library version, so setting
these is recommended only when required for compatibility with specific
client versions.
Clients do not use ``PCMK_dh_max_bits``.
* - .. _pcmk_ipc_type:
.. index::
pair: node option; PCMK_ipc_type
PCMK_ipc_type
- :ref:`enumeration <enumeration>`
- shared-mem
- *Advanced Use Only:* Force use of a particular IPC method. Allowed values:
* ``shared-mem``
* ``socket``
* ``posix``
* ``sysv``
* - .. _pcmk_ipc_buffer:
.. index::
pair: node option; PCMK_ipc_buffer
PCMK_ipc_buffer
- :ref:`nonnegative integer <nonnegative_integer>`
- 131072
- *Advanced Use Only:* Specify an IPC buffer size in bytes. This can be
useful when connecting to large clusters that result in messages
exceeding the default size (which will also result in log messages
referencing this variable).
* - .. _pcmk_cluster_type:
.. index::
pair: node option; PCMK_cluster_type
PCMK_cluster_type
- :ref:`enumeration <enumeration>`
- corosync
- *Advanced Use Only:* Specify the cluster layer to be used. If unset,
Pacemaker will detect and use a supported cluster layer, if available.
Currently, ``"corosync"`` is the only supported cluster layer. If
multiple layers are supported in the future, this will allow overriding
Pacemaker's automatic detection to select a specific one.
* - .. _pcmk_schema_directory:
.. index::
pair: node option; PCMK_schema_directory
PCMK_schema_directory
- :ref:`text <text>`
- |CRM_SCHEMA_DIRECTORY|
- *Advanced Use Only:* Specify an alternate location for RNG schemas and
XSL transforms.
* - .. _pcmk_remote_schema_directory:
.. index::
pair: node option; PCMK_remote_schema_directory
PCMK_remote_schema_directory
- :ref:`text <text>`
- |PCMK__REMOTE_SCHEMA_DIR|
- *Advanced Use Only:* Specify an alternate location on Pacemaker Remote
nodes for storing newer RNG schemas and XSL transforms fetched from
the cluster.
* - .. _pcmk_valgrind_enabled:
.. index::
pair: node option; PCMK_valgrind_enabled
PCMK_valgrind_enabled
- :ref:`enumeration <enumeration>`
- no
- *Advanced Use Only:* Whether subsystem daemons should be run under
``valgrind``. Allowed values are the same as for ``PCMK_debug``.
* - .. _pcmk_callgrind_enabled:
.. index::
pair: node option; PCMK_callgrind_enabled
PCMK_callgrind_enabled
- :ref:`enumeration <enumeration>`
- no
- *Advanced Use Only:* Whether subsystem daemons should be run under
``valgrind`` with the ``callgrind`` tool enabled. Allowed values are the
same as for ``PCMK_debug``.
* - .. _sbd_sync_resource_startup:
.. index::
pair:: node option; SBD_SYNC_RESOURCE_STARTUP
SBD_SYNC_RESOURCE_STARTUP
- :ref:`boolean <boolean>`
-
- If true, ``pacemakerd`` waits for a ping from ``sbd`` during startup
before starting other Pacemaker daemons, and during shutdown after
stopping other Pacemaker daemons but before exiting. Default value is set
based on the ``--with-sbd-sync-default`` configure script option.
* - .. _sbd_watchdog_timeout:
.. index::
pair:: node option; SBD_WATCHDOG_TIMEOUT
SBD_WATCHDOG_TIMEOUT
- :ref:`duration <duration>`
-
- If the ``stonith-watchdog-timeout`` cluster property is set to a negative
or invalid value, use double this value as the default if positive, or
use 0 as the default otherwise. This value must be greater than the value
of ``stonith-watchdog-timeout`` if both are set.
* - .. _valgrind_opts:
.. index::
pair: node option; VALGRIND_OPTS
VALGRIND_OPTS
- :ref:`text <text>`
-
- *Advanced Use Only:* Pass these options to valgrind, when enabled (see
``valgrind(1)``). ``"--vgdb=no"`` should usually be specified because
``pacemaker-execd`` can lower privileges when executing commands, which
would otherwise leave a bunch of unremovable files in ``/tmp``.
diff --git a/doc/sphinx/Pacemaker_Explained/rules.rst b/doc/sphinx/Pacemaker_Explained/rules.rst
index 52aee2b2fa..484b085e4a 100644
--- a/doc/sphinx/Pacemaker_Explained/rules.rst
+++ b/doc/sphinx/Pacemaker_Explained/rules.rst
@@ -1,1018 +1,1029 @@
.. index::
single: rule
.. _rules:
Rules
-----
Rules can be used to make your configuration more dynamic, allowing values to
change depending on the time or the value of a node attribute. Examples of
things rules are useful for:
* Set a higher value for :ref:`resource-stickiness <resource-stickiness>`
during working hours, to minimize downtime, and a lower value on weekends, to
allow resources to move to their most preferred locations when people aren't
around to notice.
* Automatically place the cluster into maintenance mode during a scheduled
maintenance window.
* Assign certain nodes and resources to a particular department via custom
node attributes and meta-attributes, and add a single location constraint
that restricts the department's resources to run only on those nodes.
Each constraint type or property set that supports rules may contain one or more
``rule`` elements specifying conditions under which the constraint or properties
take effect. Examples later in this chapter will make this clearer.
.. index::
pair: XML element; rule
Rule Properties
###############
.. table:: **Attributes of a rule Element**
:widths: 1 1 3
+-----------------+-------------+-------------------------------------------+
| Attribute | Default | Description |
+=================+=============+===========================================+
| id | | .. index:: |
| | | pair: rule; id |
| | | |
| | | A unique name for this element (required) |
+-----------------+-------------+-------------------------------------------+
| role | ``Started`` | .. index:: |
| | | pair: rule; role |
| | | |
| | | The rule is in effect only when the |
| | | resource is in the specified role. |
| | | Allowed values are ``Started``, |
| | | ``Unpromoted``, and ``Promoted``. A rule |
| | | with a ``role`` of ``Promoted`` cannot |
| | | determine the initial location of a clone |
| | | instance and will only affect which of |
| | | the active instances will be promoted. |
+-----------------+-------------+-------------------------------------------+
| score | | .. index:: |
| | | pair: rule; score |
| | | |
| | | If this rule is used in a location |
| | | constraint and evaluates to true, apply |
| | | this score to the constraint. Only one of |
| | | ``score`` and ``score-attribute`` may be |
| | | used. |
+-----------------+-------------+-------------------------------------------+
| score-attribute | | .. index:: |
| | | pair: rule; score-attribute |
| | | |
| | | If this rule is used in a location |
| | | constraint and evaluates to true, use the |
| | | value of this node attribute as the score |
| | | to apply to the constraint. Only one of |
| | | ``score`` and ``score-attribute`` may be |
| | | used. |
+-----------------+-------------+-------------------------------------------+
| boolean-op | ``and`` | .. index:: |
| | | pair: rule; boolean-op |
| | | |
| | | If this rule contains more than one |
| | | condition, a value of ``and`` specifies |
| | | that the rule evaluates to true only if |
| | | all conditions are true, and a value of |
| | | ``or`` specifies that the rule evaluates |
| | | to true if any condition is true. |
+-----------------+-------------+-------------------------------------------+
A ``rule`` element must contain one or more conditions. A condition may be an
``expression`` element, a ``date_expression`` element, or another ``rule`` element.
.. index::
single: rule; node attribute expression
single: node attribute; rule expression
pair: XML element; expression
.. _node_attribute_expressions:
Node Attribute Expressions
##########################
Expressions are rule conditions based on the values of node attributes.
.. table:: **Attributes of an expression Element**
:class: longtable
:widths: 1 2 3
+--------------+---------------------------------+-------------------------------------------+
| Attribute | Default | Description |
+==============+=================================+===========================================+
| id | | .. index:: |
| | | pair: expression; id |
| | | |
| | | A unique name for this element (required) |
+--------------+---------------------------------+-------------------------------------------+
| attribute | | .. index:: |
| | | pair: expression; attribute |
| | | |
| | | The node attribute to test (required) |
+--------------+---------------------------------+-------------------------------------------+
| type | The default type for | .. index:: |
| | ``lt``, ``gt``, ``lte``, and | pair: expression; type |
| | ``gte`` operations is ``number``| |
| | if either value contains a | How the node attributes should be |
| | decimal point character, or | compared. Allowed values are ``string``, |
| | ``integer`` otherwise. The | ``integer`` *(since 2.0.5)*, ``number``, |
| | default type for all other | and ``version``. ``integer`` truncates |
| | operations is ``string``. If a | floating-point values if necessary before |
| | numeric parse fails for either | performing a 64-bit integer comparison. |
| | value, then the values are | ``number`` performs a double-precision |
| | compared as type ``string``. | floating-point comparison |
| | | *(32-bit integer before 2.0.5)*. |
+--------------+---------------------------------+-------------------------------------------+
| operation | | .. index:: |
| | | pair: expression; operation |
| | | |
| | | The comparison to perform (required). |
| | | Allowed values: |
| | | |
| | | * ``lt:`` True if the node attribute value|
| | | is less than the comparison value |
| | | * ``gt:`` True if the node attribute value|
| | | is greater than the comparison value |
| | | * ``lte:`` True if the node attribute |
| | | value is less than or equal to the |
| | | comparison value |
| | | * ``gte:`` True if the node attribute |
| | | value is greater than or equal to the |
| | | comparison value |
| | | * ``eq:`` True if the node attribute value|
| | | is equal to the comparison value |
| | | * ``ne:`` True if the node attribute value|
| | | is not equal to the comparison value |
| | | * ``defined:`` True if the node has the |
| | | named attribute |
| | | * ``not_defined:`` True if the node does |
| | | not have the named attribute |
+--------------+---------------------------------+-------------------------------------------+
| value | | .. index:: |
| | | pair: expression; value |
| | | |
| | | User-supplied value for comparison |
| | | (required for operations other than |
| | | ``defined`` and ``not_defined``) |
+--------------+---------------------------------+-------------------------------------------+
| value-source | ``literal`` | .. index:: |
| | | pair: expression; value-source |
| | | |
| | | How the ``value`` is derived. Allowed |
| | | values: |
| | | |
| | | * ``literal``: ``value`` is a literal |
| | | string to compare against |
| | | * ``param``: ``value`` is the name of a |
| | | resource parameter to compare against |
| | | (only valid in location constraints) |
| | | * ``meta``: ``value`` is the name of a |
| | | resource meta-attribute to compare |
| | | against (only valid in location |
| | | constraints) |
+--------------+---------------------------------+-------------------------------------------+
.. _node-attribute-expressions-special:
In addition to custom node attributes defined by the administrator, the cluster
defines special, built-in node attributes for each node that can also be used
in rule expressions.
.. table:: **Built-in Node Attributes**
:widths: 1 4
+---------------+-----------------------------------------------------------+
| Name | Value |
+===============+===========================================================+
| #uname | :ref:`Node name <node_name>` |
+---------------+-----------------------------------------------------------+
| #id | Node ID |
+---------------+-----------------------------------------------------------+
| #kind | Node type. Possible values are ``cluster``, ``remote``, |
| | and ``container``. Kind is ``remote`` for Pacemaker Remote|
| | nodes created with the ``ocf:pacemaker:remote`` resource, |
| | and ``container`` for Pacemaker Remote guest nodes and |
| | bundle nodes |
+---------------+-----------------------------------------------------------+
| #is_dc | ``true`` if this node is the cluster's Designated |
| | Controller (DC), ``false`` otherwise |
+---------------+-----------------------------------------------------------+
| #cluster-name | The value of the ``cluster-name`` cluster property, if set|
+---------------+-----------------------------------------------------------+
| #site-name | The value of the ``site-name`` node attribute, if set, |
| | otherwise identical to ``#cluster-name`` |
+---------------+-----------------------------------------------------------+
.. Add_to_above_table_if_released:
+---------------+-----------------------------------------------------------+
| #ra-version | The installed version of the resource agent on the node, |
| | as defined by the ``version`` attribute of the |
| | ``resource-agent`` tag in the agent's metadata. Valid only|
| | within rules controlling resource options. This can be |
| | useful during rolling upgrades of a backward-incompatible |
| | resource agent. *(since x.x.x)* |
.. index::
single: rule; date/time expression
pair: XML element; date_expression
Date/Time Expressions
#####################
-Date/time expressions are rule conditions based (as the name suggests) on the
-current date and time.
-
+Date/time expressions are rule conditions based on the current date and time.
A ``date_expression`` element may optionally contain a ``date_spec`` or
-``duration`` element depending on the context.
-
-.. table:: **Attributes of a date_expression Element**
- :widths: 1 4
-
- +---------------+-----------------------------------------------------------+
- | Attribute | Description |
- +===============+===========================================================+
- | id | .. index:: |
- | | pair: id; date_expression |
- | | |
- | | A unique name for this element (required) |
- +---------------+-----------------------------------------------------------+
- | start | .. index:: |
- | | pair: start; date_expression |
- | | |
- | | A date/time conforming to the |
- | | `ISO8601 <https://en.wikipedia.org/wiki/ISO_8601>`_ |
- | | specification. May be used when ``operation`` is |
- | | ``in_range`` (in which case at least one of ``start`` or |
- | | ``end`` must be specified) or ``gt`` (in which case |
- | | ``start`` is required). |
- +---------------+-----------------------------------------------------------+
- | end | .. index:: |
- | | pair: end; date_expression |
- | | |
- | | A date/time conforming to the |
- | | `ISO8601 <https://en.wikipedia.org/wiki/ISO_8601>`_ |
- | | specification. May be used when ``operation`` is |
- | | ``in_range`` (in which case at least one of ``start`` or |
- | | ``end`` must be specified) or ``lt`` (in which case |
- | | ``end`` is required). |
- +---------------+-----------------------------------------------------------+
- | operation | .. index:: |
- | | pair: operation; date_expression |
- | | |
- | | Compares the current date/time with the start and/or end |
- | | date, depending on the context. Allowed values: |
- | | |
- | | * ``gt:`` True if the current date/time is after ``start``|
- | | * ``lt:`` True if the current date/time is before ``end`` |
- | | * ``in_range:`` True if the current date/time is after |
- | | ``start`` (if specified) and before either ``end`` (if |
- | | specified) or ``start`` plus the value of the |
- | | ``duration`` element (if one is contained in the |
- | | ``date_expression``). If both ``end`` and ``duration`` |
- | | are specified, ``duration`` is ignored. |
- | | * ``date_spec:`` True if the current date/time matches |
- | | the specification given in the contained ``date_spec`` |
- | | element (described below) |
- +---------------+-----------------------------------------------------------+
-
-
-.. note:: There is no ``eq``, ``neq``, ``gte``, or ``lte`` operation, since
- they would be valid only for a single second.
+``duration`` element depending on the ``operation`` as described below.
+.. list-table:: **Attributes of a date_expression Element**
+ :class: longtable
+ :widths: 1 1 1 4
+ :header-rows: 1
+
+ * - Name
+ - Type
+ - Default
+ - Description
+ * - .. _date_expression_id:
+
+ .. index::
+ pair: id; date_expression
+
+ id
+ - :ref:`id <id>`
+ -
+ - A unique name for this element (required)
+ * - .. _date_expression_start:
+
+ .. index::
+ pair: start; date_expression
+
+ start
+ - :ref:`ISO 8601 <iso8601>`
+ -
+ - The beginning of the desired time range. Meaningful with an
+ ``operation`` of ``in_range`` or ``gt``.
+ * - .. _date_expression_end:
+
+ .. index::
+ pair: end; date_expression
+
+ end
+ - :ref:`ISO 8601 <iso8601>`
+ -
+ - The end of the desired time range. Meaningful with an ``operation`` of
+ ``in_range`` or ``lt``.
+ * - .. _date_expression_operation:
+
+ .. index::
+ pair: operation; date_expression
+
+ operation
+ - :ref:`enumeration <enumeration>`
+ - ``in_range``
+ - Specifies how to compare the current date/time against a desired time
+ range. Allowed values:
+
+ * ``gt:`` The expression passes if the current date/time is after
+ ``start`` (which is required)
+ * ``lt:`` The expression passes if the current date/time is before
+ ``end`` (which is required)
+ * ``in_range:`` The expression passes if the current date/time is
+ greater than or equal to ``start`` (if specified) and less than or
+ equal to either ``end`` (if specified) or ``start`` plus the value of
+ the :ref:`duration <duration_element>` element (if one is contained in
+ the ``date_expression``). At least one of ``start`` or ``end`` must be
+ specified. If both ``end`` and ``duration`` are specified,
+ ``duration`` is ignored.
+ * ``date_spec:`` The expression passes if the current date/time matches
+ the specification given in the contained
+ :ref:`date_spec <date_spec>` element (which is required)
+
+.. _date_spec:
.. index::
single: date specification
pair: XML element; date_spec
Date Specifications
___________________
A ``date_spec`` element is used to create a cron-like expression relating
to time. Each field can contain a single number or range. Any field not
supplied is ignored.
.. table:: **Attributes of a date_spec Element**
:widths: 1 3
+---------------+-----------------------------------------------------------+
| Attribute | Description |
+===============+===========================================================+
| id | .. index:: |
| | pair: id; date_spec |
| | |
| | A unique name for this element (required) |
+---------------+-----------------------------------------------------------+
| seconds | .. index:: |
| | pair: seconds; date_spec |
| | |
| | Allowed values: 0-59 |
+---------------+-----------------------------------------------------------+
| minutes | .. index:: |
| | pair: minutes; date_spec |
| | |
| | Allowed values: 0-59 |
+---------------+-----------------------------------------------------------+
| hours | .. index:: |
| | pair: hours; date_spec |
| | |
| | Allowed values: 0-23 (where 0 is midnight and 23 is |
| | 11 p.m.) |
+---------------+-----------------------------------------------------------+
| monthdays | .. index:: |
| | pair: monthdays; date_spec |
| | |
| | Allowed values: 1-31 (depending on month and year) |
+---------------+-----------------------------------------------------------+
| weekdays | .. index:: |
| | pair: weekdays; date_spec |
| | |
| | Allowed values: 1-7 (where 1 is Monday and 7 is Sunday) |
+---------------+-----------------------------------------------------------+
| yeardays | .. index:: |
| | pair: yeardays; date_spec |
| | |
| | Allowed values: 1-366 (depending on the year) |
+---------------+-----------------------------------------------------------+
| months | .. index:: |
| | pair: months; date_spec |
| | |
| | Allowed values: 1-12 |
+---------------+-----------------------------------------------------------+
| weeks | .. index:: |
| | pair: weeks; date_spec |
| | |
| | Allowed values: 1-53 (depending on weekyear) |
+---------------+-----------------------------------------------------------+
| years | .. index:: |
| | pair: years; date_spec |
| | |
| | Year according to the Gregorian calendar |
+---------------+-----------------------------------------------------------+
| weekyears | .. index:: |
| | pair: weekyears; date_spec |
| | |
| | Year in which the week started; for example, 1 January |
| | 2005 can be specified in ISO 8601 as "2005-001 Ordinal", |
| | "2005-01-01 Gregorian" or "2004-W53-6 Weekly" and thus |
| | would match ``years="2005"`` or ``weekyears="2004"`` |
+---------------+-----------------------------------------------------------+
| moon | .. index:: |
| | pair: moon; date_spec |
| | |
| | Allowed values are 0-7 (where 0 is the new moon and 4 is |
| | full moon). *(deprecated since 2.1.6)* |
+---------------+-----------------------------------------------------------+
For example, ``monthdays="1"`` matches the first day of every month, and
``hours="09-17"`` matches the hours between 9 a.m. and 5 p.m. (inclusive).
At this time, multiple ranges (e.g. ``weekdays="1,2"`` or ``weekdays="1-2,5-6"``)
are not supported.
.. note:: Pacemaker can calculate when evaluation of a ``date_expression`` with
an ``operation`` of ``gt``, ``lt``, or ``in_range`` will next change,
and schedule a cluster re-check for that time. However, it does not
do this for ``date_spec``. Instead, it evaluates the ``date_spec``
whenever a cluster re-check naturally happens via a cluster event or
the ``cluster-recheck-interval`` cluster option.
For example, if you have a ``date_spec`` enabling a resource from 9
a.m. to 5 p.m., and ``cluster-recheck-interval`` has been set to 5
minutes, then sometime between 9 a.m. and 9:05 a.m. the cluster would
notice that it needs to start the resource, and sometime between 5
p.m. and 5:05 p.m. it would realize that it needs to stop the
resource. The timing of the actual start and stop actions will
further depend on factors such as any other actions the cluster may
need to perform first, and the load of the machine.
+.. _duration_element:
+
.. index::
single: duration
pair: XML element; duration
Durations
_________
A ``duration`` is used to calculate a value for ``end`` when one is not
supplied to ``in_range`` operations. It contains one or more attributes each
containing a single number. Any attribute not supplied is ignored.
.. table:: **Attributes of a duration Element**
:widths: 1 3
+---------------+-----------------------------------------------------------+
| Attribute | Description |
+===============+===========================================================+
| id | .. index:: |
| | pair: id; duration |
| | |
| | A unique name for this element (required) |
+---------------+-----------------------------------------------------------+
| seconds | .. index:: |
| | pair: seconds; duration |
| | |
| | This many seconds will be added to the total duration |
+---------------+-----------------------------------------------------------+
| minutes | .. index:: |
| | pair: minutes; duration |
| | |
| | This many minutes will be added to the total duration |
+---------------+-----------------------------------------------------------+
| hours | .. index:: |
| | pair: hours; duration |
| | |
| | This many hours will be added to the total duration |
+---------------+-----------------------------------------------------------+
| days | .. index:: |
| | pair: days; duration |
| | |
| | This many days will be added to the total duration |
+---------------+-----------------------------------------------------------+
| weeks | .. index:: |
| | pair: weeks; duration |
| | |
| | This many weeks will be added to the total duration |
+---------------+-----------------------------------------------------------+
| months | .. index:: |
| | pair: months; duration |
| | |
| | This many months will be added to the total duration |
+---------------+-----------------------------------------------------------+
| years | .. index:: |
| | pair: years; duration |
| | |
| | This many years will be added to the total duration |
+---------------+-----------------------------------------------------------+
Example Time-Based Expressions
______________________________
A small sample of how time-based expressions can be used:
.. topic:: True if now is any time in the year 2005
.. code-block:: xml
<rule id="rule1" score="INFINITY">
<date_expression id="date_expr1" start="2005-001" operation="in_range">
<duration id="duration1" years="1"/>
</date_expression>
</rule>
or equivalently:
.. code-block:: xml
<rule id="rule2" score="INFINITY">
<date_expression id="date_expr2" operation="date_spec">
<date_spec id="date_spec2" years="2005"/>
</date_expression>
</rule>
.. topic:: 9 a.m. to 5 p.m. Monday through Friday
.. code-block:: xml
<rule id="rule3" score="INFINITY">
<date_expression id="date_expr3" operation="date_spec">
<date_spec id="date_spec3" hours="9-16" weekdays="1-5"/>
</date_expression>
</rule>
Note that the ``16`` matches all the way through ``16:59:59``, because the
numeric value of the hour still matches.
.. topic:: 9 a.m. to 6 p.m. Monday through Friday or anytime Saturday
.. code-block:: xml
<rule id="rule4" score="INFINITY" boolean-op="or">
<date_expression id="date_expr4-1" operation="date_spec">
<date_spec id="date_spec4-1" hours="9-16" weekdays="1-5"/>
</date_expression>
<date_expression id="date_expr4-2" operation="date_spec">
<date_spec id="date_spec4-2" weekdays="6"/>
</date_expression>
</rule>
.. topic:: 9 a.m. to 5 p.m. or 9 p.m. to 12 a.m. Monday through Friday
.. code-block:: xml
<rule id="rule5" score="INFINITY" boolean-op="and">
<rule id="rule5-nested1" score="INFINITY" boolean-op="or">
<date_expression id="date_expr5-1" operation="date_spec">
<date_spec id="date_spec5-1" hours="9-16"/>
</date_expression>
<date_expression id="date_expr5-2" operation="date_spec">
<date_spec id="date_spec5-2" hours="21-23"/>
</date_expression>
</rule>
<date_expression id="date_expr5-3" operation="date_spec">
<date_spec id="date_spec5-3" weekdays="1-5"/>
</date_expression>
</rule>
.. topic:: Mondays in March 2005
.. code-block:: xml
<rule id="rule6" score="INFINITY" boolean-op="and">
<date_expression id="date_expr6-1" operation="date_spec">
<date_spec id="date_spec6" weekdays="1"/>
</date_expression>
<date_expression id="date_expr6-2" operation="in_range"
start="2005-03-01" end="2005-04-01"/>
</date_expression>
</rule>
.. note:: Because no time is specified with the above dates, 00:00:00 is
implied. This means that the range includes all of 2005-03-01 but
- none of 2005-04-01. You may wish to write ``end`` as
- ``"2005-03-31T23:59:59"`` to avoid confusion.
+ only the first second of 2005-04-01. You may wish to write ``end``
+ as ``"2005-03-31T23:59:59"`` to avoid confusion.
.. index::
single: rule; resource expression
single: resource; rule expression
pair: XML element; rsc_expression
Resource Expressions
####################
An ``rsc_expression`` *(since 2.0.5)* is a rule condition based on a resource
agent's properties. This rule is only valid within an ``rsc_defaults`` or
``op_defaults`` context. None of the matching attributes of ``class``,
``provider``, and ``type`` are required. If one is omitted, all values of that
attribute will match. For instance, omitting ``type`` means every type will
match.
.. table:: **Attributes of a rsc_expression Element**
:widths: 1 3
+---------------+-----------------------------------------------------------+
| Attribute | Description |
+===============+===========================================================+
| id | .. index:: |
| | pair: id; rsc_expression |
| | |
| | A unique name for this element (required) |
+---------------+-----------------------------------------------------------+
| class | .. index:: |
| | pair: class; rsc_expression |
| | |
| | The standard name to be matched against resource agents |
+---------------+-----------------------------------------------------------+
| provider | .. index:: |
| | pair: provider; rsc_expression |
| | |
| | If given, the vendor to be matched against resource |
| | agents (only relevant when ``class`` is ``ocf``) |
+---------------+-----------------------------------------------------------+
| type | .. index:: |
| | pair: type; rsc_expression |
| | |
| | The name of the resource agent to be matched |
+---------------+-----------------------------------------------------------+
Example Resource-Based Expressions
__________________________________
A small sample of how resource-based expressions can be used:
.. topic:: True for all ``ocf:heartbeat:IPaddr2`` resources
.. code-block:: xml
<rule id="rule1" score="INFINITY">
<rsc_expression id="rule_expr1" class="ocf" provider="heartbeat" type="IPaddr2"/>
</rule>
.. topic:: Provider doesn't apply to non-OCF resources
.. code-block:: xml
<rule id="rule2" score="INFINITY">
<rsc_expression id="rule_expr2" class="stonith" type="fence_xvm"/>
</rule>
.. index::
single: rule; operation expression
single: operation; rule expression
pair: XML element; op_expression
Operation Expressions
#####################
An ``op_expression`` *(since 2.0.5)* is a rule condition based on an action of
some resource agent. This rule is only valid within an ``op_defaults`` context.
.. table:: **Attributes of an op_expression Element**
:widths: 1 3
+---------------+-----------------------------------------------------------+
| Attribute | Description |
+===============+===========================================================+
| id | .. index:: |
| | pair: id; op_expression |
| | |
| | A unique name for this element (required) |
+---------------+-----------------------------------------------------------+
| name | .. index:: |
| | pair: name; op_expression |
| | |
| | The action name to match against. This can be any action |
| | supported by the resource agent; common values include |
| | ``monitor``, ``start``, and ``stop`` (required). |
+---------------+-----------------------------------------------------------+
| interval | .. index:: |
| | pair: interval; op_expression |
| | |
| | The interval of the action to match against. If not given,|
| | only the name attribute will be used to match. |
+---------------+-----------------------------------------------------------+
Example Operation-Based Expressions
___________________________________
A small sample of how operation-based expressions can be used:
.. topic:: True for all monitor actions
.. code-block:: xml
<rule id="rule1" score="INFINITY">
<op_expression id="rule_expr1" name="monitor"/>
</rule>
.. topic:: True for all monitor actions with a 10 second interval
.. code-block:: xml
<rule id="rule2" score="INFINITY">
<op_expression id="rule_expr2" name="monitor" interval="10s"/>
</rule>
.. index::
pair: location constraint; rule
Using Rules to Determine Resource Location
##########################################
A location constraint may contain one or more top-level rules. The cluster will
act as if there is a separate location constraint for each rule that evaluates
as true.
Consider the following simple location constraint:
.. topic:: Prevent resource ``webserver`` from running on node ``node3``
.. code-block:: xml
<rsc_location id="ban-apache-on-node3" rsc="webserver"
score="-INFINITY" node="node3"/>
The same constraint can be more verbosely written using a rule:
.. topic:: Prevent resource ``webserver`` from running on node ``node3`` using a rule
.. code-block:: xml
<rsc_location id="ban-apache-on-node3" rsc="webserver">
<rule id="ban-apache-rule" score="-INFINITY">
<expression id="ban-apache-expr" attribute="#uname"
operation="eq" value="node3"/>
</rule>
</rsc_location>
The advantage of using the expanded form is that one could add more expressions
(for example, limiting the constraint to certain days of the week), or activate
the constraint by some node attribute other than node name.
Location Rules Based on Other Node Properties
_____________________________________________
The expanded form allows us to match on node properties other than its name.
If we rated each machine's CPU power such that the cluster had the following
nodes section:
.. topic:: Sample node section with node attributes
.. code-block:: xml
<nodes>
<node id="uuid1" uname="c001n01" type="normal">
<instance_attributes id="uuid1-custom_attrs">
<nvpair id="uuid1-cpu_mips" name="cpu_mips" value="1234"/>
</instance_attributes>
</node>
<node id="uuid2" uname="c001n02" type="normal">
<instance_attributes id="uuid2-custom_attrs">
<nvpair id="uuid2-cpu_mips" name="cpu_mips" value="5678"/>
</instance_attributes>
</node>
</nodes>
then we could prevent resources from running on underpowered machines with this
rule:
.. topic:: Rule using a node attribute (to be used inside a location constraint)
.. code-block:: xml
<rule id="need-more-power-rule" score="-INFINITY">
<expression id="need-more-power-expr" attribute="cpu_mips"
operation="lt" value="3000"/>
</rule>
Using ``score-attribute`` Instead of ``score``
______________________________________________
When using ``score-attribute`` instead of ``score``, each node matched by the
rule has its score adjusted differently, according to its value for the named
node attribute. Thus, in the previous example, if a rule inside a location
constraint for a resource used ``score-attribute="cpu_mips"``, ``c001n01``
would have its preference to run the resource increased by ``1234`` whereas
``c001n02`` would have its preference increased by ``5678``.
.. _s-rsc-pattern-rules:
Specifying location scores using pattern submatches
___________________________________________________
Location constraints may use ``rsc-pattern`` to apply the constraint to all
resources whose IDs match the given pattern (see :ref:`s-rsc-pattern`). The
pattern may contain up to 9 submatches in parentheses, whose values may be used
as ``%1`` through ``%9`` in a rule's ``score-attribute`` or a rule expression's
``attribute``.
As an example, the following configuration (only relevant parts are shown)
gives the resources **server-httpd** and **ip-httpd** a preference of 100 on
**node1** and 50 on **node2**, and **ip-gateway** a preference of -100 on
**node1** and 200 on **node2**.
.. topic:: Location constraint using submatches
.. code-block:: xml
<nodes>
<node id="1" uname="node1">
<instance_attributes id="node1-attrs">
<nvpair id="node1-prefer-httpd" name="prefer-httpd" value="100"/>
<nvpair id="node1-prefer-gateway" name="prefer-gateway" value="-100"/>
</instance_attributes>
</node>
<node id="2" uname="node2">
<instance_attributes id="node2-attrs">
<nvpair id="node2-prefer-httpd" name="prefer-httpd" value="50"/>
<nvpair id="node2-prefer-gateway" name="prefer-gateway" value="200"/>
</instance_attributes>
</node>
</nodes>
<resources>
<primitive id="server-httpd" class="ocf" provider="heartbeat" type="apache"/>
<primitive id="ip-httpd" class="ocf" provider="heartbeat" type="IPaddr2"/>
<primitive id="ip-gateway" class="ocf" provider="heartbeat" type="IPaddr2"/>
</resources>
<constraints>
<!-- The following constraint says that for any resource whose name
starts with "server-" or "ip-", that resource's preference for a
node is the value of the node attribute named "prefer-" followed
by the part of the resource name after "server-" or "ip-",
wherever such a node attribute is defined.
-->
<rsc_location id="location1" rsc-pattern="(server|ip)-(.*)">
<rule id="location1-rule1" score-attribute="prefer-%2">
<expression id="location1-rule1-expression1" attribute="prefer-%2" operation="defined"/>
</rule>
</rsc_location>
</constraints>
.. index::
pair: cluster option; rule
pair: instance attribute; rule
pair: meta-attribute; rule
pair: resource defaults; rule
pair: operation defaults; rule
pair: node attribute; rule
Using Rules to Define Options
#############################
Rules may be used to control a variety of options:
* :ref:`Cluster options <cluster_options>` (``cluster_property_set`` elements)
* :ref:`Node attributes <node_attributes>` (``instance_attributes`` or
``utilization`` elements inside a ``node`` element)
* :ref:`Resource options <resource_options>` (``utilization``,
``meta_attributes``, or ``instance_attributes`` elements inside a resource
definition element or ``op`` , ``rsc_defaults``, ``op_defaults``, or
``template`` element)
* :ref:`Operation properties <operation_properties>` (``meta_attributes``
elements inside an ``op`` or ``op_defaults`` element)
.. note::
Attribute-based expressions for meta-attributes can only be used within
``operations`` and ``op_defaults``. They will not work with resource
configuration or ``rsc_defaults``. Additionally, attribute-based
expressions cannot be used with cluster options.
Using Rules to Control Resource Options
_______________________________________
Often some cluster nodes will be different from their peers. Sometimes,
these differences -- e.g. the location of a binary or the names of network
interfaces -- require resources to be configured differently depending
on the machine they're hosted on.
By defining multiple ``instance_attributes`` objects for the resource and
adding a rule to each, we can easily handle these special cases.
In the example below, ``mySpecialRsc`` will use eth1 and port 9999 when run on
``node1``, eth2 and port 8888 on ``node2`` and default to eth0 and port 9999
for all other nodes.
.. topic:: Defining different resource options based on the node name
.. code-block:: xml
<primitive id="mySpecialRsc" class="ocf" type="Special" provider="me">
<instance_attributes id="special-node1" score="3">
<rule id="node1-special-case" score="INFINITY" >
<expression id="node1-special-case-expr" attribute="#uname"
operation="eq" value="node1"/>
</rule>
<nvpair id="node1-interface" name="interface" value="eth1"/>
</instance_attributes>
<instance_attributes id="special-node2" score="2" >
<rule id="node2-special-case" score="INFINITY">
<expression id="node2-special-case-expr" attribute="#uname"
operation="eq" value="node2"/>
</rule>
<nvpair id="node2-interface" name="interface" value="eth2"/>
<nvpair id="node2-port" name="port" value="8888"/>
</instance_attributes>
<instance_attributes id="defaults" score="1" >
<nvpair id="default-interface" name="interface" value="eth0"/>
<nvpair id="default-port" name="port" value="9999"/>
</instance_attributes>
</primitive>
The order in which ``instance_attributes`` objects are evaluated is determined
by their score (highest to lowest). If not supplied, the score defaults to
zero. Objects with an equal score are processed in their listed order. If the
``instance_attributes`` object has no rule, or a ``rule`` that evaluates to
``true``, then for any parameter the resource does not yet have a value for,
the resource will use the parameter values defined by the ``instance_attributes``.
For example, given the configuration above, if the resource is placed on
``node1``:
* ``special-node1`` has the highest score (3) and so is evaluated first; its
rule evaluates to ``true``, so ``interface`` is set to ``eth1``.
* ``special-node2`` is evaluated next with score 2, but its rule evaluates to
``false``, so it is ignored.
* ``defaults`` is evaluated last with score 1, and has no rule, so its values
are examined; ``interface`` is already defined, so the value here is not
used, but ``port`` is not yet defined, so ``port`` is set to ``9999``.
Using Rules to Control Resource Defaults
________________________________________
Rules can be used for resource and operation defaults. The following example
illustrates how to set a different ``resource-stickiness`` value during and
outside work hours. This allows resources to automatically move back to their
most preferred hosts, but at a time that (in theory) does not interfere with
business activities.
.. topic:: Change ``resource-stickiness`` during working hours
.. code-block:: xml
<rsc_defaults>
<meta_attributes id="core-hours" score="2">
<rule id="core-hour-rule" score="0">
<date_expression id="nine-to-five-Mon-to-Fri" operation="date_spec">
<date_spec id="nine-to-five-Mon-to-Fri-spec" hours="9-16" weekdays="1-5"/>
</date_expression>
</rule>
<nvpair id="core-stickiness" name="resource-stickiness" value="INFINITY"/>
</meta_attributes>
<meta_attributes id="after-hours" score="1" >
<nvpair id="after-stickiness" name="resource-stickiness" value="0"/>
</meta_attributes>
</rsc_defaults>
Rules may be used similarly in ``instance_attributes`` or ``utilization``
blocks.
Any single block may directly contain only a single rule, but that rule may
itself contain any number of rules.
``rsc_expression`` and ``op_expression`` blocks may additionally be used to
set defaults on either a single resource or across an entire class of resources
with a single rule. ``rsc_expression`` may be used to select resource agents
within both ``rsc_defaults`` and ``op_defaults``, while ``op_expression`` may
only be used within ``op_defaults``. If multiple rules succeed for a given
resource agent, the last one specified will be the one that takes effect. As
with any other rule, boolean operations may be used to make more complicated
expressions.
.. topic:: Default all IPaddr2 resources to stopped
.. code-block:: xml
<rsc_defaults>
<meta_attributes id="op-target-role">
<rule id="op-target-role-rule" score="INFINITY">
<rsc_expression id="op-target-role-expr" class="ocf" provider="heartbeat"
type="IPaddr2"/>
</rule>
<nvpair id="op-target-role-nvpair" name="target-role" value="Stopped"/>
</meta_attributes>
</rsc_defaults>
.. topic:: Default all monitor action timeouts to 7 seconds
.. code-block:: xml
<op_defaults>
<meta_attributes id="op-monitor-defaults">
<rule id="op-monitor-default-rule" score="INFINITY">
<op_expression id="op-monitor-default-expr" name="monitor"/>
</rule>
<nvpair id="op-monitor-timeout" name="timeout" value="7s"/>
</meta_attributes>
</op_defaults>
.. topic:: Default the timeout on all 10-second-interval monitor actions on ``IPaddr2`` resources to 8 seconds
.. code-block:: xml
<op_defaults>
<meta_attributes id="op-monitor-and">
<rule id="op-monitor-and-rule" score="INFINITY">
<rsc_expression id="op-monitor-and-rsc-expr" class="ocf" provider="heartbeat"
type="IPaddr2"/>
<op_expression id="op-monitor-and-op-expr" name="monitor" interval="10s"/>
</rule>
<nvpair id="op-monitor-and-timeout" name="timeout" value="8s"/>
</meta_attributes>
</op_defaults>
.. index::
pair: rule; cluster option
Using Rules to Control Cluster Options
______________________________________
Controlling cluster options is achieved in much the same manner as specifying
different resource options on different nodes.
The following example illustrates how to set ``maintenance_mode`` during a
scheduled maintenance window. This will keep the cluster running but not
monitor, start, or stop resources during this time.
.. topic:: Schedule a maintenance window for 9 to 11 p.m. CDT Sept. 20, 2019
.. code-block:: xml
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<nvpair id="bootstrap-stonith-enabled" name="stonith-enabled" value="1"/>
</cluster_property_set>
<cluster_property_set id="normal-set" score="10">
<nvpair id="normal-maintenance-mode" name="maintenance-mode" value="false"/>
</cluster_property_set>
<cluster_property_set id="maintenance-window-set" score="1000">
<nvpair id="maintenance-nvpair1" name="maintenance-mode" value="true"/>
<rule id="maintenance-rule1" score="INFINITY">
<date_expression id="maintenance-date1" operation="in_range"
start="2019-09-20 21:00:00 -05:00" end="2019-09-20 23:00:00 -05:00"/>
</rule>
</cluster_property_set>
</crm_config>
.. important:: The ``cluster_property_set`` with an ``id`` set to
"cib-bootstrap-options" will *always* have the highest priority,
regardless of any scores. Therefore, rules in another
``cluster_property_set`` can never take effect for any
properties listed in the bootstrap set.