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

[Tim Serong]

On 5/4/2011 at 08:49 PM, Andrew Beekhof <andrew at beekhof.net> wrote: 
> Tick tock.  I'm going to push this soon unless someone raises an objection  
> RSN. 

This is going into 1.1, right?

Do existing CIBs automagically get updated to this syntax, or does the
admin have to force this?  (Sorry, I forget if that was covered already).

Thanks,

Tim

>  
> 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. 
> > 
>  
> _______________________________________________ 
> 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.