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

[Dejan Muhamedagic]

Hi,

On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote:
> 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.

So, the internal-collocation replaces the sequential attribute?
What are the possible and/or meaningfull values for
internal-collocation? It looks like that would be 0 or INFINITY
only, which would translate to old sequential false and true,
right?

Looking at the schema, the ordering constraint lost score and is
using only the kind attribute which can have one of:

      <value>None</value>
      <value>Optional</value>
      <value>Mandatory</value>
      <value>Serialize</value>

But then, the "kind" attribute is optional. If missing, how's
that different from value None?

What does Serialize mean? (in orders)

What does score-attribute-mangle mean? (in collocations)

It's good that finally the role/action got next to the resource.

I think that it'd be good to clarify the shell syntax before
applying these changes.

Thanks,

Dejan

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