----- Original Message ----- > From: "Phil Frost" <p...@macprofessionals.com> > To: pacemaker@oss.clusterlabs.org > Sent: Monday, June 18, 2012 10:39:24 AM > Subject: Re: [Pacemaker] Confusing semantics of colocation sets (stopping > resource stops others in colocation / order > sets) > > 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:
I think you're confusing how resource sets get created... they are created by having more than two resources in the statement; then it creates the different sets based upon like roles listed in order. The parenthesis make them non-sequential; they don't define how to create the set. > > 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? I don't know if you've looked at the cli documentation but it might be helpful since the cli does differ slightly in syntax from the xml: http://www.clusterlabs.org/doc/crm_cli.html Jake > > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > 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 > > _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org 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
