Rules can be used to make your configuration more dynamic. One common example is to set one value for resource-stickiness during working hours, to prevent resources from being moved back to their most preferred location, and another on weekends when no-one is around to notice an outage.
Another use of rules might be to assign machines to different processing groups (using a node attribute) based on time and to then use that attribute when creating location constraints.
Each rule can contain a number of expressions, date-expressions and even other rules. The results of the expressions are combined based on the rule’s boolean-op field to determine if the rule ultimately evaluates to true or false. What happens next depends on the context in which the rule is being used.
Table 8.1. Properties of a Rule
|
Field
|
Default
|
Description
|
|---|
|
id
|
|
A unique name for the rule (required)
|
|
role
|
Started
|
Limits the rule to apply only when the resource is in the specified role. Allowed values are Started, Slave, and Master. A rule with role="Master" cannot determine the initial location of a clone instance and will only affect which of the active instances will be promoted.
|
|
score
|
|
The score to apply if the rule evaluates to true. Limited to use in rules that are part of location constraints.
|
|
score-attribute
|
|
The node attribute to look up and use as a score if the rule evaluates to true. Limited to use in rules that are part of location constraints.
|
|
boolean-op
|
and
|
How to combine the result of multiple expression objects. Allowed values are and and or.
|
