>>> Tim Serong <[email protected]> schrieb am 11.07.2011 um 15:51 in Nachricht <[email protected]>: [...] > You probably want to flip the colocation constraint: > > colocation col_rksapr00_saprouter_ping inf: \ > prm_rksapr00_ping grp_rksapr00
Yes I did that once I realized that it's directed. [...] > Have a look at > http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s- > > resource-colocation.html > and the following few pages. Also Colocation Explained at > http://clusterlabs.org/wiki/Documentation. > > The key point being "you can't place A relative to B unless you know > where B is", so colocation with Pacemaker necessarily involves a > dependency. AIUI implementing fully "symmetric colocation" would mean Note: The "colocation explained document" is a void link in there! I have nothing against a dependency, but something against a "running dependency": Treated symmetrically, it does not matter who is running first, A or B. Only when the other (A or B) comes up, the colocation should be considered, either placing the newer resource closer or further away from the other resource. > Pacemaker may need a semi-infinite amount of time to figure out WTF a > given colocation constraint means. This is undesirable. Yes, it's like placing a block optimally in a filesystem. Fortunately most filesystems need little time and don't place the blocks that badly. Does the current system implement transitivity, i.e. colocation(A,B), colocation (B,C) -> colocation(A,C). I guess that's one root of the problems. Also when requiring disjunct sets of colocations the problems should be easy to handle. When ignoring the running state, "colocation foo A inf: B" would be fulfilled if B is not up. When B comes up, it would have to run where A is, or A should be migrated to where B started. The +/- infinity cases should be easy to handle at least. I'm just wondering if a "first match" rule for colocations would help us here (Still there are other constraints like priority and location which make things more complicated) Regards, Ulrich _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
