Hi,

On Mon, Oct 04, 2010 at 10:36:21PM +0200, Andreas Kurz wrote:
> Hello,
> 
> On 10/04/2010 05:36 PM, Dejan Muhamedagic wrote:
> > Hi,
> > 
> > On Mon, Oct 04, 2010 at 04:01:50PM +0100, Matthew Richardson wrote:
> > I've been playing with pacemaker for a while now, and have recently
> > seena  user stung by an issue I had when I first started - namely that
> > colocation constraints are limited to 2 entries, unless sets are used.
> > 
> > Thus:
> > 
> > colocation ok inf: A B
> > 
> > is allowed (obviously!)
> > 
> > colocation sets_ok inf: A (B) (C)
> > 
> > is also allowed.
> > 
> > However:
> > 
> > colocation not_ok inf: A B C
> > 
> > isn't valid, though a user might expect it to be equal to the set-based
> > contraint.
> > 
> >> Hmm, last time I looked it worked. How do you know that it's not
> >> valid?
> 
> I think what Matthew means is:
> 
> colocation ok inf: A B ... produces a colocation constraint A-follows-B
> 
> colocation not_ok inf: A B C ... implicitely configures a resource set
> expressing C-follows-B-follows-A, which is exatly the other way round.
> 
> colocation sets_ok inf: A (B) (C) ... configures three resource sets
> that behave like (as a lot of user seem to expect from the previous
> example) A-follows-B-follows-C

Oops.

> Dejan, what are your thougts about let the shell "hide" the reversed
> behavior of colocation resource sets and let this:
> 
> colocation not_ok inf: A B ( C D ) F G
> 
> ... create:
> 
> <rsc_colocation id="not_ok" score="INFINITY" >
>       <resource_set id="collocated-set-1" sequential="true">
>         <resource_ref id="B"/>
>         <resource_ref id="A"/>
>       </resource_set>
>       <resource_set id="collocated-set-2" sequential="false">
>         <resource_ref id="D"/>
>         <resource_ref id="C"/>
>       </resource_set>
>       <resource_set id="collocated-set-3" sequential="true">
>         <resource_ref id="G"/>
>         <resource_ref id="F"/>
>       </resource_set>
> </rsc_colocation>

I'm not sure. Either that or to introduce brackets as Andrew
suggested once earlier. That would be:

colocation not_ok inf: [ A B ] ( C D ) [ F G ]

or shouldn't it actually be like this:

colocation not_ok inf: [ F G ] ( C D ) [ A B ]

> ... or convince Andrew to change resource sets to _not_ have the same
> colocation semantics as groups ... whatever is easier ;-)

A good one :) Anyway, it's too late to change the semantics as
that would change behaviour of the existing clusters.

I still find all this confusing.

Cheers,

Dejan

> Regards,
> Andreas
> 
> > 
> >> Thanks,
> > 
> >> Dejan
> > 
> > I would like to suggest 2 potential solutions to this:
> > 
> > 1) (simple) Provide a warning/error message when someone constructs this
> > invalid constraint.
> > 
> > 2) (more complex) Translate this constraint to a meaningful set - i.e
> > change 'A B C' to 'A (B) (C)'
> > 
> > I'm not sure whether or not the 2nd option makes sense or whether it
> > adds some extra level of confusion or uncertainty to its behaviour.
> > 
> > Any comments?  I'm happy to do some work to submit a patch to the shell
> > to at least do the basic checking, though this might not be the best
> > place (or indeed the best patch) to achieve these, if people think
> > they're worthwhile suggestions.
> > 
> > Thanks,
> > 
> > Matthew
> > 
> >>
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> >>
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
> > _______________________________________________
> > Linux-HA mailing list
> > [email protected]
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> 
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
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