----- Original Message ----- > From: "Phil Frost" <[email protected]> > To: [email protected] > 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 _______________________________________________ Pacemaker mailing list: [email protected] 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
