[ClusterLabs] Antw: [EXT] Coming in Pacemaker 2.0.1: build-time default for resource-stickiness
Ulrich.Windl at rz.uni-regensburg.de
Thu Apr 15 03:02:46 EDT 2021
>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 14.04.2021 um 19:46 in
<6b9a088d07369cc39a82c1ff3af41c43c10b34a2.camel at redhat.com>:
> Hello all,
> I hope to have the first Pacemaker 2.0.1 release candidate ready next
> A recently added feature is a new build‑time option to change the
> resource‑stickiness default for new CIBs.
> Currently, resource‑stickiness defaults to 0, meaning the cluster is
> free to move resources around to balance them across nodes and so
> forth. Many new users are surprised by this behavior and expect sticky
> behavior by default.
Well I think zero stickiness is good to teach new users that the cluster will
move any resource unless told otherwise.
> Now, building Pacemaker using ./configure ‑‑with‑resource‑stickiness‑
> default=<N> tells Pacemaker to add a rsc_defaults section to empty CIBs
> with a resource‑stickiness of <N>. Distributions and users who build
> from source can set this if they're tried of explaining stickiness to
> surprised users and expect fewer users to be surprised by stickiness.
Hopefully there will be great variability between distributions, and releases
also, so that users will lears that it's best to set the stickiness as needed
> Adding a resource default to all new CIBs is an unusual way of changing
> a default.
> We can't simply leave it to higher‑level tools, because when creating a
> cluster, the cluster may not be started immediately and thus there is
> no way to set the property. Also, the user has a variety of ways to
> create or start a cluster, so no tool can assume it has full control.
> We leave the implicit default stickiness at 0, and instead set the
> configured default via a rsc_defaults entry in new CIBs, so that it
> won't affect existing clusters or rolling upgrades (current users won't
> see behavior change), and unlike implicit defaults, users can query and
> remove resource defaults.
IMHO implicit values are great if they never vary, and there is common
agreement what the ("reasonable") default value is.
Obviously that is not the case, so maybe it's better not to have any implicit
(default) values; instead require to specify them (as a global default) all.
> Ken Gaillot <kgaillot at redhat.com>
> Manage your subscription:
> ClusterLabs home: https://www.clusterlabs.org/
More information about the Users