On Wed, Oct 6, 2010 at 1:19 AM, Andreas Kurz <[email protected]> wrote: > On 10/05/2010 06:03 PM, Andrew Beekhof wrote: >> On Tue, Oct 5, 2010 at 3:47 PM, Dejan Muhamedagic <[email protected]> >> 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 ] > > For the xml-snippet above this ^^^^^ would be ok IMHO > > {A-follows-B}-follow-{C and D)} -- C and D with no interdependencies > > {C and D}-follow-{F-follows-G} > > ... please correct me if this is nonsense! > >>> >>> or shouldn't it actually be like this: >>> >>> colocation not_ok inf: [ F G ] ( C D ) [ A B ] >> >> This one is correct > > I assume you mean for this xml-code?
nope > ... or correct me again ;-) think of a group, the colocation goes from bottom to top and the ordering goes from top to bottom > > <rsc_colocation id="not_ok" score="INFINITY" > > <resource_set id="collocated-set-1" sequential="true"> > <resource_ref id="G"/> > <resource_ref id="F"/> > </resource_set> > <resource_set id="collocated-set-2" sequential="false"> > <resource_ref id="C"/> > <resource_ref id="D"/> > </resource_set> > <resource_set id="collocated-set-3" sequential="true"> > <resource_ref id="B"/> > <resource_ref id="A"/> > </resource_set> > </rsc_colocation> > > Regards, > Andreas > >> >>> >>>> ... 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 >> >>> >>> 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 >>> >> _______________________________________________ >> 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
