[ClusterLabs] Antw: [EXT] Coming in Pacemaker 2.0.5: finer control over resource and operation defaults

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Fri Jul 24 03:15:54 EDT 2020

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 23.07.2020 um 23:54 in
<99c11c73d59560fccd472d09c3b76073dab1b73e.camel at redhat.com>:
> Hi all,
> Pacemaker 2.0.4 is barely out the door, and we're already looking ahead
> to 2.0.5, expected at the end of this year.
> One of the new features, already available in the master branch, will
> be finer‑grained control over resource and operation defaults.
> Currently, you can set meta‑attribute values in the CIB's rsc_defaults
> section to apply to all resources, and op_defaults to apply to all
> operations. Rules can be used to apply defaults only during certain
> times. For example, to set a default stickiness of INFINITY during
> business hours and 0 outside those hours:
>    <rsc_defaults>
>     <meta_attributes id="business‑hours" score="2">
>       <rule id="business‑hours‑rule" score="0">
>         <date_expression id="business‑hours‑expr" operation="date_spec">
>           <date_spec id="business‑hours‑spec" hours="9‑17" weekdays="1‑5"/>
>         </date_expression>
>       </rule>
>       <nvpair id="business‑hours‑stickiness" name="resource‑stickiness" 
> value="INFINITY"/>
>     </meta_attributes>
>     <meta_attributes id="after‑hours" score="1" >
>       <nvpair id="after‑hours‑stickiness" name="resource‑stickiness"
>     </meta_attributes>
>    </rsc_defaults>
> But what if you want to change the default stickiness of just pgsql
> databases? Or the default timeout of only start operations?

We are using a rather similar scenario, like the stickyness. However we
distinguish between productive and "no so productive" (test, developement)
resources. First we release the stickiness of non-essential resources so that
they can be re-balanced if needed. Later when the productive resources are
released, the nodes maybe balanced already using the non-essential resources.

At the moment we copied the rules to each resource, which is not nice, of

I'd appreciate:
date_spec be defined once and reused often
rule be defined once and reused often

> 2.0.5 will add new rule expressions for this purpose. Examples:
>    <rsc_defaults>
>     <meta_attributes id="pgsql‑defaults" score="2">
>       <rule id="pgsql‑defaults‑rule" score="0">
>         <rsc_expression id="pgsql‑defaults‑expr" class="ocf" 
> provider="heartbeat" type="pgsqlms"/>
>       </rule>
>       <nvpair id="pgsql‑stickiness" name="resource‑stickiness" 
> value="INFINITY"/>
>     </meta_attributes>
>    </rsc_defaults>
>    <op_defaults>
>     <meta_attributes id="start‑defaults" score="2">
>       <rule id="start‑defaults‑rule" score="0">
>         <op_expression id="start‑defaults‑expr" name="start" interval="0"/>
>       </rule>
>       <nvpair id="start‑timeout" name="timeout" value="60s"/>
>     </meta_attributes>
>    </op_defaults>
> You can combine rsc_expression and op_expression in op_defaults rules,
> if for example you want to set a default stop timeout for all
> ocf:heartbeat:docker resources.
> This obviously can be convenient if you have many resources of the same
> type, but it has one other trick up its sleeve: this is the only way
> you can affect the meta‑attributes of resources implicitly created by
> Pacemaker for bundles.
> When you configure a bundle, Pacemaker will implicitly create container
> resources (ocf:heartbeat:docker, ocf:heartbeat:rkt, or
> ocf:heartbeat:podman) and if appropriate, IP resources
> (ocf:heartbeat:IPaddr2). Previously, there was no way to directly
> affect these resources, but with these new expressions you can at least
> configure defaults that apply to them, without having to use those same
> defaults for all your resources.
> ‑‑ 
> Ken Gaillot <kgaillot at redhat.com>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> ClusterLabs home: https://www.clusterlabs.org/ 

More information about the Users mailing list