>>> Ken Gaillot <kgail...@redhat.com> schrieb am 23.07.2020 um 23:54 in Nachricht <99c11c73d59560fccd472d09c3b76073dab1b73e.ca...@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" value="0"/> > </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 course. 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 <kgail...@redhat.com> > > _______________________________________________ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/