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

Lars Marowsky-Bree lmb at novell.com
Fri Apr 15 09:00:18 EDT 2011


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? If so, three cheers. ;-)

Can you share the proposed schema and XSLT, if you already have some?

> >>      <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?

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

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

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


> >>         <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?


Regards,
    Lars

-- 
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde





More information about the Pacemaker mailing list