Hi, On Mon, Jul 11, 2011 at 4:14 PM, Ulrich Windl < [email protected]> 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 ... \ > 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 ... \ > 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 > > > > > > 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: > > 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. > > > > > > > > IMHO: colocation should not affect the running state of resources: If A > and > > B should have a infinity colocation, that constraint should be still > > fulfilled if only one of both (A, B) is running. Specifically > "colocation" is > > not a symmetrical version of "depends_on" ("requires") > > > > Can you please stop broadcasting your own opinion before you establish > > the facts and/or understand the underlying concepts? Or is your opinion > > set in stone already, and facts would merely confuse you? > > Well actually I feel you just don't like any opinion others than your own. And, in retrospect, given the rather lengthy set of well intended comments you've given so far (whilst still _respecting the opinion and work of others and not enforcing your own ideas on to the topic_) it may seem that you have been misguided into a career that doesn't really fit you best, ever thought about taking up counseling for people with suicidal tendencies? You'd be of _real_ use there. It's not that I want to be right; it's just that I feel I'm right. Many people suffer from delusions of grandeur, there's medicine for that. > When talking about colocation in general (as in the last paragraph), I'm > not talking about the specific implementation in pacemaker. Ok, then do it somewhere else because this mailing list addresses Pacemaker and adjacent software solutions that work with or in relation to it. Either that or bring relevant information to the topic instead of complaints about people's work (e.g.: relevant information is not what you've done so far, there's another set of not so polite terms for that). You've criticized just about anyone whom has ever worked on this cluster stack, soon, people are going to stop trying to be nice in their replies or ignore you altogether. Then you can complain to your upper management that there's no support from the community for this cluster stack and go back to the paid solution you've probably used thus far. Again, if I haven't said it, I will say this now, people here are more than willing to help, however they are not paid to put up with a condescending tone. You want support: http://www.clusterlabs.org/wiki/Support#Professional_Support Best regards, Dan > Only the concrete example referred to the concrete implementation. > > Regards, > Ulrich > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > -- Dan Frincu CCNA, RHCE _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
