Is there a way to avoid have score:INFINITY when use 'pcs resource move' ?
Environment
Red Hat Enterprise Linux 7 High Availability
Issue
When I use command 'pcs resource move' Pacemaker set that resource with INFINITY score, no matter the stickiness values I set. Is there a way to avoid this?
Resolution
No. There is no way to avoid the score INFINITY when use 'pcs resource move' due the meaning of "move" word.
Root Cause
The 'pcs resource move' operation shouldn't be thought of as trying to achieve a parallel goal as what 'clusvcadm -r' did with rgmanager. rgmanager didn't have the advanced constraint functionality that pacemaker does, so essentially it was just one node being preferred over another and the relocate option was made available to give a little more control to the administrator. With pacemaker, that means of control is already available through the constraint functionality that dictates where and how the resources should run, so this same functionality should also be used for on-the-fly reconfiguration of where/how that resource runs.
A lot of the confusion that comes with 'pcs resource move' is usually based around the usage of the term "move". We should not think of it as "move it to a location of my choosing for now", but rather it should be viewed as the help output states it: "Move resource off current node (and optionally onto destination node).". So the point is to get the resource OFF of the current node, and that is what the constraint achieves. With the functionality that pacemaker provides, its important that the location and ordering of a resource be deterministic. If we were to allow moving a resource around contrary to what its constraints say, then those constraints effectively become meaningless; if you moved a resource to a specific location and it had constraints and stickiness values that said it should do otherwise, then when do we fall back into using those constraints again? What if another node joins that has a higher score? We moved to the current node outside what the rules say, so should we now adhere to the rules or respect what the administrator wanted? Using constraints is much cleaner, as it ensures that there are clear rules that dictate what has happened and what will happen next.
So, this probably should just be a training exercise in helping the customer understand how best to achieve what they want. If they'd like to temporarily prefer a single member but otherwise still rely on the other constraints and resource-stickiness values, then they can just 'pcs constraint location
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
