On 10/06/2010 08:35 AM, Andrew Beekhof wrote: > 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
hmmm ... hmmm ... everything is fine ;-) my interpretion of how resource-sets work is ok ... but I interpreted the suggested crm syntax wrong > > >> >> <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 > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
