>>> 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. It's
not that I want to be right; it's just that I feel I'm right. When talking
about colocation in general (as in the last paragraph), I'm not talking about
the specific implementation in pacemaker. 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
