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

Andrew Beekhof andrew at beekhof.net
Wed Oct 6 00:35:03 MDT 2010


On Wed, Oct 6, 2010 at 1:19 AM, Andreas Kurz <andreas.kurz at linbit.com> wrote:
> On 10/05/2010 06:03 PM, 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 ]
>
> 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
>>>> 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
>
> _______________________________________________
> 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