[Pacemaker] [pacemaker][patch 3/4] Simple changes for "Pacemaker Explained", Chapter 6 CH_Constraints.xml
Andrew Beekhof
andrew at beekhof.net
Sat Apr 16 00:55:51 CET 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: 5380 bytes
Desc: not available
URL: <http://oss.clusterlabs.org/pipermail/pacemaker/attachments/20110415/c77cde04/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upgrade12.xsl
Type: text/xml
Size: 4417 bytes
Desc: not available
URL: <http://oss.clusterlabs.org/pipermail/pacemaker/attachments/20110415/c77cde04/attachment-0001.xml>
More information about the Pacemaker
mailing list