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

[Phil Frost]

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:

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?