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

[Andrew Beekhof]

Tick tock.  I'm going to push this soon unless someone raises an objection RSN.

On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
> 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.
>