On 4/21/07, Yan Fitterer <[EMAIL PROTECTED]> wrote:


>>> On Fri, Apr 20, 2007 at 10:05 PM, in message
<[EMAIL PROTECTED]>, "Andrew Beekhof"
<[EMAIL PROTECTED]> wrote:
> If rsc_colocation and rsc_location were the same then we wouldn't need
> two names, but they are different and behave accordingly.

I suppose I'm struggling with the fact that apply -INFINITY rsc_location 
constraints can make a resource unable to run anywhere, whilst +INFINITY can't 
do that.

This alone makes them inexact inverses. -> unintuitive.

but I suppose as Alan said, "it's an idiom, learn it!"

>
> If anything, rsc_colocation would be changed to be more like
> rsc_location but there are technical and cognitive limitations that
> currently prevent this.

whatever happens here, I hope you agree we _must_ keep the ability to force two 
resource to colocate, or fail (at least one) to run.

>
> The idea of having +INFINITY (in the context of rsc_location) mean a
> resource can _only_ run on that node is more than slightly absurd for
> a _high_availability_ project.

mmm. I do see your point. From that point of view, having to specify a number 
of -INFINITY resources it fine by me.

the best way to do it it with a -INFINITY rule and an expression of
uname != nodeWhereItShouldRun

that way you only need 1 rule and any new nodes added to the cluster
wont be considered either


>
> Perhaps thats why I rarely need to explain this -  because very few
> people want to add resources that run only on one node.  It also
> sounds like you should be using symmetric_cluster=false as that seems
> more appropriate for the type of cluster you're building.

Not sure about that. I still have about 18 resources that should be treated 
symmetrically, and only 1 that doesn't.

In that case, which should win?

either can be made to work, but one method will be "shorter" - ie.
require less configuration.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to