[Pacemaker] Confusing semantics of colocation sets (stopping resource stops others in colocation / order sets)
Jake Smith
jsmith at argotec.com
Fri Jun 15 21:00:07 UTC 2012
----- 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
More information about the Pacemaker
mailing list