[Pacemaker] [pacemaker][patch 3/4] Simple changes for "Pacemaker Explained", Chapter 6 CH_Constraints.xml

Andrew Beekhof andrew at beekhof.net
Mon Apr 11 12:02:30 EDT 2011 

On Mon, Apr 11, 2011 at 3:41 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
> On Mon, Apr 11, 2011 at 2:33 PM, Tim Serong <tserong at novell.com> wrote:
>>> >> > For members within a set (sequential=true), it is true that for a given
>>> >> > member to be active, the previous members must also be active.
>>> >> >
>>> >> > Between sets however, it's the other way around - a given set depends on
>>> >> > the subsequent set.
>>> >>
>>> >> Did I really write it like that? You tested it?
>>> >
>>> > Yup.  Well, I tested it (pcmk 1.1.5), so I assume you wrote it like that :)
>>> >
>>> > We want (pardon the ASCII art):
>>> >
>>> >             /--> C --\
>>> >  G --> F --+---> D ---+--> B --> A
>>> >             \- -> E --/
>>> >
>>> > Test is:
>>> >
>>> >  # crm configure colocation c inf: F G ( C D E ) A B
>>>
>>> Given the well discussed issues with the shell syntax, I'd prefer to
>>> see the raw xml actually.
>>
>>    <constraints>
>>      <rsc_colocation id="c" score="INFINITY">
>>        <resource_set id="c-0">
>>          <resource_ref id="F"/>
>>          <resource_ref id="G"/>
>>        </resource_set>
>>        <resource_set id="c-1" sequential="false">
>>          <resource_ref id="C"/>
>>          <resource_ref id="D"/>
>>          <resource_ref id="E"/>
>>        </resource_set>
>>        <resource_set id="c-2">
>>          <resource_ref id="A"/>
>>          <resource_ref id="B"/>
>>        </resource_set>
>>      </rsc_colocation>
>>    </constraints>
>
> So, at least for colocation,

s/at least//

I double checked ordering constraints and they work as I think they should.
The basic equivalent to c-2 would be "first=A then=B" which I believe
makes sense.
And if the sets were collapsed, the equivalent is "first=c-0 then=c-1,
first=c-1 then=c-2" which is again the ordering you'd get from a
group.

So it looks like we "just" need to fix the order in which colocation
sets are processed.
I already know how to use xslt for the conversion, we just need to
finalize the syntax.

> it looks like we want either the order
> within the set to be the reverse of what it is now.
> Ie.
>
>         <resource_set id="c-2">
>           <resource_ref id="B"/>
>           <resource_ref id="A"/>
>         </resource_set>
>
> Or the order of the sets reversed (so as to work like groups).

On further reflection, I'm pretty sure this is what we want (and what
I had intended originally).

> Ie.
>
>         <resource_set id="c-2">
>           <resource_ref id="A"/>
>           <resource_ref id="B"/>
>         </resource_set>
>         <resource_set id="c-1" sequential="false">
>           <resource_ref id="C"/>
>           <resource_ref id="D"/>
>           <resource_ref id="E"/>
>         </resource_set>
>         <resource_set id="c-0">
>           <resource_ref id="F"/>
>           <resource_ref id="G"/>
>         </resource_set>
>
> Which do people think is going to be more comprehendible?
>
> Since we want new behavior, we should use a new syntax to be able to
> distinguish between the two.
> Which is handy because the existing syntax is clearly challenging.
>
> At a minimum we want s/resource_set/colocation_set/g
>
> Two additional open questions, How to indicate the scores:
> - between the sets
>  Keep using the score from the constraint?
> - between resources within a set (sequential is clearly too confusing).
>
> Perhaps with internal_score and external_score attributes for colocation_set's.
> Where the value of external_score on colocation_set N reflects the
> colocation preference with set N-1 (ie. the one above it in xml
> syntax).
>
> And also:
> - how to deal with roles and instances sanely?
>
>
> In pseudo DTD syntax, I think we're looking at something like:
>
> colocation_set ::= id, resource_ref+, internal_score?

I've changed internal_score to internal-colocation=boolean
Ordering sets will get similar treatment.

Between the sets, the score/kind from the enclosing constraint should
be sufficient but I'd be happy to hear if anyone can think of
something we cant express properly.

>
> resource_ref ::= id-ref, action?, role?, instance?
>
> With the whole between sets thing to be still worked out.
>
>>> >  # crm resource stop F
>>> >     (stops F and G)
>>> >  # crm resource start F
>>> >  # crm resource stop D
>>> >     (stops D, F and G)
>>> >  # crm resource start D
>>> >  # crm resource stop B
>>> >     (stops everything except A)
>>> >
>>> > That shell colocation constraint maps exactly to the (new) XML shown below
>>> > (verified just in case it turned out to be a shell oddity).
>>> >
>>> >> If so, thats just retarded and needs an overhaul.
>>> >
>>> > It is a little... confusing.
>>> >
>>> > Regards,
>>> >
>>> > Tim
>>> >
>>> >> >
>>> >> > The example colocation chain in Pacemaker Explained right now should thus
>>> >> > be changed as follows in order to match the diagram:
>>> >> >
>>> >> >  <constraints>
>>> >> >    <rsc_colocation id="coloc-1" score="INFINITY" >
>>> >> >       <resource_set id="collocated-set-1" sequential="true">
>>> >> > -        <resource_ref id="A"/>
>>> >> > -        <resource_ref id="B"/>
>>> >> > +        <resource_ref id="F"/>
>>> >> > +        <resource_ref id="G"/>
>>> >> >      </resource_set>
>>> >> >      <resource_set id="collocated-set-2" sequential="false">
>>> >> >        <resource_ref id="C"/>
>>> >> >        <resource_ref id="D"/>
>>> >> >        <resource_ref id="E"/>
>>> >> >      </resource_set>
>>> >> >      <resource_set id="collocated-set-2" sequential="true" role="Master">
>>> >> > -        <resource_ref id="F"/>
>>> >> > -        <resource_ref id="G"/>
>>> >> > +        <resource_ref id="A"/>
>>> >> > +        <resource_ref id="B"/>
>>> >> >      </resource_set>
>>> >> >    </rsc_colocation>
>>> >> >  </constraints>
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> > Tim
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Tim Serong <tserong at novell.com>
>>> >> > Senior Clustering Engineer, OPS Engineering, Novell Inc.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> >> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>> >> >
>>> >> > Project Home: http://www.clusterlabs.org
>>> >> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> >> > Bugs:
>>> >> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Tim Serong <tserong at novell.com>
>>> > Senior Clustering Engineer, OPS Engineering, Novell Inc.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>> >
>>> > Project Home: http://www.clusterlabs.org
>>> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> > Bugs:
>>> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>> >
>>>
>>
>>
>>
>>
>> --
>> Tim Serong <tserong at novell.com>
>> Senior Clustering Engineer, OPS Engineering, Novell Inc.
>>
>>
>>
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>
>

More information about the Pacemaker mailing list