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

[Phil Frost]

On 06/14/2012 05:47 PM, Jake Smith wrote:
> So it should be resC on top of resB on top of DRBD:master. I think of 
> collocation as being written in the reverse order of "order" 
> statement. That's why resources in groups start in the order they are 
> written and collocate in reverse from written order.
>
> Second and this may or may not be right (travelling so I can't check 
> right now).  It could also be creating a resource group inside the 
> collocation statement.

It is creating a resource set. What I think you are saying (and 
experimentation seems to support this) is that the ordering of 
colocation dependencies is in the opposite direction for resources 
within a resource set than it is between sets. So:

# simple colocation, no sets
colocation colo inf: A B
# A -> B

# creates one set
colocation colo inf: A B C
# C -> B -> A

# creates three sets
colocation colo inf: A B (C D) E F
# B -> A -> (C, D) -> F -> E

# also creates three sets
colocation colo inf: A B C:Master D E
# B -> A -> C -> E -> D

I...uh...don't really know what to say. Is that a bug, in that it is not 
reasonable in any way? Or is it a feature, in that it can't be fixed in 
a backwards compatible way?

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 
"Configuration Explained" [1]. What about implementing a new syntax 
explicitly notating a sequential resource group, and deprecating 
previous syntax for such (more than two resources, or ":<state>")?

Also noteworthy is that "Configuration Explained" is very wrong on this 
issue. It says:

"in order for any member of set N to be active, all the members of set 
N+1 must also be active (and naturally on the same node); and if a set 
has |sequential="true"|, then in order for member M to be active, member 
M+1 must also be active."

What it should say is:

"in order for member M to be active, member *M-1* must also be active."

In the same way, the graphic is wrong.

Here's another interesting observation:

colocation colo inf: (A B C)

is not an error, but does absolutely nothing.

[1] 
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-sets-collocation.html