[ClusterLabs] Q: Resource Groups vs Resources for stickiness and colocation?

[Ken Gaillot]

On Wed, 2018-08-29 at 18:40 +0100, Ian Underhill wrote:
> im guessing this is just a "feature", but something that will
> probably stop me using groups
> 
> Scenario1 (working):
> 1) Two nodes (1,2) within a cluster (default-stickiness = INFINITY)
> 2) Two resources (A,B) in a cluster running on different nodes 
> 3) colocation constraint between resources of A->B score=-1
> 
> a) pcs standby node2, the resource B moves to node 1
> b) pcs unstandby node2, the resource B stays on node 1 - this is good
> and expected
> 
> Secanrio 2 (working):
> 1) exactly the same as above but the resource exist within their own
> group (G1,G2)
> 2) the colocation constraint is between the groups
> 
> Secanrio 3 (not working):
> 1) Same as above however each group has two resources in them
> 
>  Resource Group: A_grp
>      A	(ocf::test:fallover):	Started mac-devl03
>      A_2	(ocf::test:fallover):	Started mac-devl03
>  Resource Group: B_grp
>      B	(ocf::test:fallover):	Started mac-devl11
>      B_2	(ocf::test:fallover):	Started mac-devl11
> 
> a) pcs standby node2, the group moves to node 1
> b) pcs unstandby node2, the group moves to node 2, but I have
> INFINITY stickiness (maybe I need INFINITY+1 ;) )????
> 
> crm_simulate -sL doesnt really explain why there is a difference.
> 
> any ideas?  (environment pacemaker-cluster-libs-1.1.16-12.el7.x86_64)
> 
> /Ian

This sounds like a bug. Feel free to submit a report at
bugs.clusterlabs.org and attach the policy engine input file with the
unexpected behavior.

FYI a group's stickiness is the sum of the stickiness of each active
member, though no score can be bigger than INFINITY.
-- 
Ken Gaillot <kgaillot at redhat.com>