On 2011-07-11 15:14, Ulrich Windl wrote: >>>> Florian Haas <[email protected]> schrieb am 11.07.2011 um 14:12 in > Nachricht <[email protected]>: >> On 2011-07-11 13:40, Ulrich Windl wrote: >>> Hi! >>> >>> I think I misunderstood "colocation": I thought a colocation means if two >> resources are running, the should be (or not) on the same node. >>> In practive however, there seems to be more: >>> I have two resources, say A and B. A has highter priority than B, and an >> ordering that B should be started after A. As B depends on resources >> provided >> by A, I also added a infnity colocation for A and B. >>> Now I'm surprised that when I tell CRM to stop B, B is stopped, but A also. >> >> It would be helpful if you shared your configuration, rather than >> paraphrased it. That way we could have figured out if your configuration >> actually matches the blurb you posted. > > OK: > primitive prm_rksapr00_ping ocf:pacemaker:ping \ > params ... \
Any specific reason why you're cutting configuration parameters out? > op monitor interval="300s" timeout="60" \ > op start interval="0" timeout="60" \ > utilization utl_cpu="1" utl_ram="1" \ > meta priority="2050" target-role="Started" > group grp_rksapr00 prm_rksapr00_ip_1 ... \ Here too? > meta priority="2000" resource-stickiness="100000" > target-role="Started" > order ord_rksapr00_ping_after_saprouter inf: grp_rksapr00 prm_rksapr00_ping > colocation col_rksapr00_saprouter_ping inf: grp_rksapr00 prm_rksapr00_ping Why is the ping resource not cloned, and what is this colocation supposed to achieve? >> It is non-obvious, from your description, how you set a "higher >> priority" for one resource over another, whether your order constraint >> is advisory or mandatory, how you placed your colocation constraint, etc. >> >>> I wanted B to be more independent of A compared to putting A and B into one >> group. >>> >>> What did I misunderstand? >> >> You probably (I'm guessing) missed the fact that colocation constraints >> are directional. They are not reversible at will. >> >> If you have a colocation constraint like >> >> inf: foo bar >> >> ... then verbalize this as "foo on bar". foo must always run "on bar", >> that is to say, on whichever node is currently managing bar. What this >> implies is that if bar isn't running anywhere, foo can't run, either. By >> contrast if foo can't run anywhere, then bar is unaffected. > > OK, so it seems you implemented a strange kind of c "colocation" that is part > of co-location, and part of "depends_on". I'd like to have clean and separate > implementations: Excellent. Send a patch! > For co-location: If "A is near B", obviously "B is near A", so co-location is > symmetric by nature. > > For "depends_on": if "A depends_on B" it makes not much sense if "B > depends_on A" (is this antisymmetric?) > > Your implementation mixed both, a symmetric and a non-symmetric relation. > Naturally this causes problems. Out of curiosity, to whom does the possessive pronoun apply? > Well actually I feel you just don't like any opinion others than your own. Says exactly who, about whom? Anyhow, naturally you are entitled to feeling whatever you like. > It's not that I want to be right; it's just that I feel I'm right. Oh! Well then of course I'll rest my case. Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
