[Pacemaker] Confusing semantics of colocation sets (stopping resource stops others in colocation / order sets)

[Jake Smith]

----- Original Message -----
> From: "Phil Frost" <phil at macprofessionals.com>
> To: pacemaker at oss.clusterlabs.org
> Sent: Monday, June 18, 2012 10:39:24 AM
> Subject: Re: [Pacemaker] Confusing semantics of colocation sets (stopping resource stops others in colocation / order
> sets)
> 
> On 06/15/2012 05:00 PM, Jake Smith wrote:
> > # also creates three sets
> > colocation colo inf: A B C:Master D E
> > # B ->  A ->  C ->  E ->  D
> > Yes because C is a stateful resource.  When you tested this I
> > assume you used Dummy resource for A,B,D,E and a Stateful resource
> > for primitive_C and created a master/slave ms_C resource to use in
> > the colocation statement?
> 
> No, just used "configure show xml" to see what CRM was doing
> actually.
> 
> >> The notion of creating a resource set when nothing in the syntax
> >> suggests is surprising. It also makes impossible some things, like
> >> a
> >> group with two resources and role="Master", such as example 6.17
> >> in
> > Can you elaborate on what you mean by "group with two resources and
> > role='Master'" is impossible?
> 
> After testing, I guess it's not impossible. It's just really
> confusing.
> Guess what this does:
> 
> colocation c inf: ( ms_A:Master ms_B:Master ms_C:Master D )
> 
> It's one non-sequential resource set, right? No, that's not possible,
> because the role is set per-set, so can't be both master and null. So
> it's an error, right? Also no. It's actually two resource sets, which
> you can see after you have CRM tell you what it did:

I think you're confusing how resource sets get created... they are created by having more than two resources in the statement; then it creates the different sets based upon like roles listed in order.  The parenthesis make them non-sequential; they don't define how to create the set.

> 
> crm(live)configure# show c
> colocation c inf: ( ms_A:Master ms_B:Master ms_C:Master ) ( D )
> 
> The problem is that CRM syntax suggests that the role is a
> per-resource
> property, but it's actually a per-resource-set property. To
> accommodate
> this disparity in syntax, it mangles what you said into a valid XML
> configuration in a complex and surprising way, and when that's
> impossible, it just does something else.
> 
> Sure, the mangling is easy to understand once you understand how the
> syntaxes are different and what mangling is necessary, but it's
> surprising, undocumented, and not otherwise useful. Wouldn't it just
> be
> better if no mangling was required?

I don't know if you've looked at the cli documentation but it might be helpful since the cli does differ slightly in syntax from the xml:

http://www.clusterlabs.org/doc/crm_cli.html

Jake

> 
> 
> _______________________________________________
> 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://bugs.clusterlabs.org
> 
>