HomeClusterLabs Projects

Refactor: scheduler: simplify applying resource stickiness

Description

Refactor: scheduler: simplify applying resource stickiness

Previously, stage2() called common_apply_stickiness() for every node/resource
combination in the cluster. However a resource can only be sticky on the node
it's active on, so it's overkill to check it on every node.

The somewhat misleadingly named common_apply_stickiness() also called
check_failure_threshold(), which does have to be done for every combination.
To keep this the same, check_failure_threshold() is now recursive in the same
manner that common_apply_stickiness() was, and stage2() now calls
check_failure_threshold() where it used to call common_apply_stickiness().

Stickiness is now handled by a new function apply_stickiness() that stage2()
calls for every resource in the cluster. Compared to common_apply_stickiness(),
it now has a doxygen block and improved variable names, formatting, and log
messages. It drops an unnecessary variable "sticky_rsc" which was a leftover
from old code, as well an overkill log dump of allowed nodes for asymmetric
clusters.

Details

Provenance
kgaillotAuthored on Jan 20 2022, 3:33 PM
Parents
rP24079a98e555: Refactor: scheduler: functionize checking migration-threshold
Branches
Unknown
Tags
Unknown

Event Timeline