Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 2011-09-23 22:24, Arnold Krille wrote: > On Friday 23 September 2011 21:23:55 Florian Haas wrote: >> On 2011-09-23 19:06, Arnold Krille wrote: >>> On Friday 23 September 2011 17:54:26 Florian Haas wrote: >>>> On 2011-09-23 14:58, Nick Khamis wrote: >>>>> colocation mysql_on_drbd \ >>>>> >>>>> inf: ms_drbd_mysql:Master HAServices >>>> >>>> Incorrect; should be "colocation mysql_on_drbd inf: HAServices >>>> ms_drbd_mysql:Master" >>> >>> As far as I understand both the docs and my practical experience, the >>> order of elements in the colocation is irrelevant. >> Not trying to challenge your experience or your understanding of the >> documentation, but the idea that colocation constraints are >> non-directional is simply a wrong assumption. >> http://www.clusterlabs.org/mwiki/images/6/61/Colocation_Explained.pdf >> Slide 2. > > Challenge accepted:) I will check my experience next week, the cluster > concerned isn't yet in productional use. Swap them around and stop or fail resources. Then it becomes evident fairly quickly. > >>> The order in groups or in order-statements however is not. >> For a group, that is of course unless is has meta ordered=false. > > Unordered groups inside ordered groups are something I have to get my head > around too. But probably my cluster definitions will be more complex than > "simple" groups inside groups because for two machines there is the chain of > drbd-ms->gfs->mount->libvirt, for the (not yet realized) extensions it will be > iscsi->gfs->mount->libvirt. And the prerequisite for virtual machine should > only be "libvirt"... You can't do nested groups. Pacemaker groups can only ever contain primitives. Resource sets are a different story. I _think_ you can actually put a group in a resource set, but that would be making things overly complicated on purpose. Florian