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. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
