On Fri, 2020-07-24 at 09:15 +0200, Ulrich Windl wrote: > > > > 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
Reusing a rule is already possible -- define it as usual in one place, and in the other use <rule id-ref="original-rule-id"/> That doesn't work for date_spec though. > > > > > 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/ -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/