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

Andrew Beekhof andrew at beekhof.net
Tue Apr 12 07:48:01 UTC 2011


Here's an example of the before and after. Thoughts?

Before:

      <rsc_colocation id="coloc-set" score="INFINITY">
        <resource_set id="coloc-set-0">
          <resource_ref id="dummy2"/>
          <resource_ref id="dummy3"/>
        </resource_set>
        <resource_set id="coloc-set-1" sequential="false" role="Master">
          <resource_ref id="dummy0"/>
          <resource_ref id="dummy1"/>
        </resource_set>
      </rsc_colocation>
      <rsc_order id="order-set" score="INFINITY">
        <resource_set id="order-set-0" role="Master">
          <resource_ref id="dummy0"/>
          <resource_ref id="dummy1"/>
        </resource_set>
        <resource_set id="order-set-1" sequential="false">
          <resource_ref id="dummy2"/>
          <resource_ref id="dummy3"/>
        </resource_set>
      </rsc_order>



After:

     <rsc_colocation id="coloc-set" score="INFINITY">
        <colocation_set id="coloc-set-1" internal-colocation="0">
          <resource_ref id="dummy0" role="Master"/>
          <resource_ref id="dummy1" role="Master"/>
        </colocation_set>
        <colocation_set id="coloc-set-0" internal-colocation="INFINITY">
          <resource_ref id="dummy2"/>
          <resource_ref id="dummy3"/>
        </colocation_set>
      </rsc_colocation>
      <rsc_order id="order-set" kind="Mandatory">
        <ordering_set id="order-set-0" internal-ordering="Mandatory">
          <resource_ref id="dummy0" role="Master"/>
          <resource_ref id="dummy1" role="Master"/>
        </ordering_set>
        <ordering_set id="order-set-1" internal-ordering="Optional">
          <resource_ref id="dummy2"/>
          <resource_ref id="dummy3"/>
        </ordering_set>
      </rsc_order>




On Mon, Apr 11, 2011 at 6:02 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
> 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