[Linux-HA] Handling colocation constraints with more than 2 entries

Dejan Muhamedagic dejanmm at fastmail.fm
Wed Oct 6 04:34:22 MDT 2010


On Tue, Oct 05, 2010 at 06:03:17PM +0200, Andrew Beekhof wrote:
> On Tue, Oct 5, 2010 at 3:47 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> > 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 ]
> 
> This one is correct
> 
> >
> >> ... or convince Andrew to change resource sets to _not_ have the same
> >> colocation semantics as groups ... whatever is easier ;-)
> >
> > A good one :)
> 
> Well its not really up to the PE to work around bugs in the shell ;-)
> 
> > Anyway, it's too late to change the semantics as
> > that would change behaviour of the existing clusters.
> 
> Actually the solution is really quite easy.
> 
> 1. Make constraints with > 2 elements and no/insufficient brackets
> produce a warning and require user confirmation.
> There is certainly precedent for things in the shell becoming warnings
> that weren't previously.
> 
> 2. Decide on two types of brackets to use, one for ordered and one for
> unordered.
> 
> 1. gives you backwards computability
> 2. gives us sanity

There's also role change which forces a break in the set. There
was posted an example like this to the list:

(a) collocation c1 inf: ms-r0:Master fs jboss

or, expressed as a chain of two-resource collocations:

collocation c1_1 inf: jboss fs
collocation c1_2 inf: fs ms-r0:Master

Now, the resource set would have to be split in two because of
the role change, but that would also force us to move stuff
around to preserve semantics:

(b) collocation c1 inf: [ fs jboss ] [ ms-r0:Master ]

Because adjacent resource sets have the same semantics as
two-resource collocations, right?

The case when the role change is in the middle:

(a) collocation c1 inf: A B:Master C

becomes

(b) collocation c1 inf: [ C ] [ B:Master ] [ A ]

All this strikes me as suboptimal, but I'm not sure what is to be
done about it.

Basically, users should be able to type the (a) versions and let
the software handle the rest.

Opinions?

Cheers,

Dejan


> >
> > 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
> >> Linux-HA at lists.linux-ha.org
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> >> See also: http://linux-ha.org/ReportingProblems
> >> > _______________________________________________
> >> > Linux-HA mailing list
> >> > Linux-HA at lists.linux-ha.org
> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> >> > See also: http://linux-ha.org/ReportingProblems
> >>
> >> _______________________________________________
> >> Linux-HA mailing list
> >> Linux-HA at lists.linux-ha.org
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> >> See also: http://linux-ha.org/ReportingProblems
> > _______________________________________________
> > Linux-HA mailing list
> > Linux-HA at lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> >
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems



More information about the Linux-HA mailing list