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

Andrew Beekhof andrew at beekhof.net
Fri Apr 15 10:55:51 EDT 2011


On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree <lmb at novell.com> wrote:
> On 2011-04-13T08:37:12, Andrew Beekhof <andrew at beekhof.net> wrote:
>
>> >> 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:
>
> So I am understanding this properly - we're getting rid of the
> "sequential" attribute, yes?

Absolutely.

> If so, three cheers. ;-)
>
> Can you share the proposed schema and XSLT, if you already have some?

Attached

>
>> >>      <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">
>
> So we have "(score|kind)" on the outside, and
> "internal-(ordering|colocation)" on the inner elements. Is there a
> particular reason to use a different name on the inner ones?

The language didn't feel right tbh - the inner ones felt like they
needed more context/clarification.
We can change the outer name too if you like.

> Also, rsc_order has either score or kind; are you doing away with that
> here?

Yes. Standardizing on "kind".  Score never made sense for ordering :-(

>
> "lifetime" would only apply to the entire element, right?

right

> And, just to be fully annoying - is there a real benefit to having
> ordering_set and colocation_set?

Very much so.  Because kind makes no sense for a colocation - and
vice-versa for score.
Using different element names means the rng can be stricter.

>
>
>> >>         <ordering_set id="order-set-1" internal-ordering="Optional">
>> >>           <resource_ref id="dummy2"/>
>
> While we're messing with sets anyway, I'd like to re-hash the idea I
> brought up on pcmk-devel. To make configuration more compact, I'd like
> to have "automatic sets" - i.e., the set of all resources that match
> something.
>
> Imagine:
>
>        <resource_list type="Xen" provider="heartbeat" class="ocf" />
>
> and suddenly all your Xen guests are correctly ordered and collocated.
> The savings in administrative complexity and CIB size are huge.
>
> Or would you rather do this via templates?

You mean something like?

  <ordering_set id="order-set-0" internal-ordering="Mandatory">
     <resource_pattern type= provider= >
  </ordering>

Might make sense.  But doesn't strictly need to be bundled with this change.
I'd be wary about allowing pattern matching on the name, I can imagine
resources ending up in multiple sets (loops!) very easily.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constraints-1.1.rng
Type: application/octet-stream
Size: 5381 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110415/c77cde04/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upgrade12.xsl
Type: text/xml
Size: 4418 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110415/c77cde04/attachment-0003.xml>


More information about the Pacemaker mailing list