[Pacemaker] resources not migrating when some are not runnable on one node, maybe because of groups or master/slave clones?

[Phil Frost]

On 06/18/2012 10:14 AM, Vladislav Bogdanov wrote:
> Sets (constraints with more then two members) are evaluated in the
> different order.
> Try
> colocation colo_drbd_master inf: ( drbd_nfsexports_ms:Master ) (
> vg_nfsexports ) ( test )

I'm sure that's the wrong order. I've put the parens on each resource to 
force crm to create three sets of one resource each. Otherwise, it would 
make two sets, one with DRBD, and one with vg_nfsexports and test. To 
maintain the correct order (that is, vg_nfsexports requires the DRBD 
master, and test requires vg_nfsexports), I'd have to write this:

colocation colo_drbd_master inf: vg_nfsexports test 
drbd_nfsexports_ms:Master [1]

As you've proposed, if "test" can't run, then nothing can. If 
"vg_nfsexports" can't run, then test can run but drbd_nfsexports_ms can 
not. If drbd_nfsexports_ms can not run, then vg_nfsexports and test are 
not affected. That's the opposite of what I think makes sense. I only 
know this because I hashed exactly this out just last week. The 
documentation is wrong, and crm's syntax is arcane and misleading. See 
here: http://oss.clusterlabs.org/pipermail/pacemaker/2012-June/014420.html

Even so, I think in a situation where some node could run all the 
resources, the intended behavior is that Pacemaker will use that 
resource placement, regardless of the ordering of the colocation 
constraint. The ordering only should come in to play when there's no 
node that can run all the resources, or when there are multiple 
solutions that run all resources and it must decide which is "best". I 
think. If I'm wrong on that point please correct me.

[1] yes, really.