[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: Friday, June 15, 2012 7:28:37 AM
> Subject: Re: [Pacemaker] Confusing semantics of colocation sets
> (stopping resource stops others in colocation / order sets)

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

Yes - glad that got through even though I had the wrong terminology and some of what I said above was inaccurate!

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

Yes

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

Yes

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

Yes

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

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

Not sure why you say it's not reasonable.  It caused a bit of confusion for me at one time but now that I understand the logic it doesn't seem like a big deal to me.

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

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

I think what you said above is correct (makes sense to me)
That's something for Andrew to weigh in on (I believe he wrote it)

> 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

Just as a side note.

When I have mixed types like this I usually write them this way which (I think) makes a bit less confusing.  Also reduces the number of statements usually.

resources drbd_A B C D E

Assuming I want them to start drbd_A:promote B C D E
And collocate E -> D -> C -> B -> drbd_A:Master

group non_stateful_group B C D E
order master_before_group drbd_A:promote non_stateful_group:start
colocate non_stateful_with_master inf: non_stateful_group drbd_A:master


Jake