On Fri, Jun 15, 2012 at 2:59 AM, Nicolaas Stuyt <nicolaas.st...@rcmp-grc.gc.ca> wrote: > Thank you for pointing me at this discussion thread. The configuration did > help me to achieve what I was looking for. Now though I wonder if I should > because of the threads end-point comment. > > Any idea what the background explanation may be for the comment: > "an unordered and/or uncolocated groups are an abomination"
Just use a colocation set instead. > > The thread stops with: > ------------------------- > Unordered and/or uncolocated groups are an abomination. > Is that enough light? > ------------------------- > > Nick > >>>> Florian Crouzat <gen...@floriancrouzat.net> 2012-06-14 09:56 >>> > > Le 14/06/2012 14:55, Nicolaas Stuyt a écrit : >> Hello, >> Is there a way to affect a groups ordering behavior? The default appears >> to be left to right which I can understand. However if I wish to create >> a group of "like primitives" and not primitives who are dependant on >> each other - for example a list of (ocf::heartbeat:Filesystem) >> primitives - then I care less about the order. I was hoping to specify a >> meta characteristic like "lazy" I guess; something like meta >> order="lazy" or "not-applicable". This ordering behavior seems to exist >> in colocation as well. >> What I wish to achieve is to take a file system resource down - say for >> maintenance and then allow it to come back when maintenance is completed >> without affecting the other Filesystem primitives down the list. >> To provide a visual illustration of this I created a cloned group of >> dummies using (ocf::pacemaker:Dummy) and I have stopped just the last >> dummy primitive: >> Clone Set: cl_dummies [grp_dummies] >> Resource Group: grp_dummies:0 >> dummy1:0 (ocf::pacemaker:Dummy): Started node1 >> dummy2:0 (ocf::pacemaker:Dummy): Started node1 >> dummy3:0 (ocf::pacemaker:Dummy): Started node1 >> dummy4:0 (ocf::pacemaker:Dummy): Started node1 >> dummy5:0 (ocf::pacemaker:Dummy): Stopped >> Resource Group: grp_dummies:1 >> dummy1:1 (ocf::pacemaker:Dummy): Started node2 >> dummy2:1 (ocf::pacemaker:Dummy): Started node2 >> dummy3:1 (ocf::pacemaker:Dummy): Started node2 >> dummy4:1 (ocf::pacemaker:Dummy): Started node2 >> dummy5:1 (ocf::pacemaker:Dummy): Stopped >> When all are running crm_mon presents as: >> Clone Set: cl_dummies [grp_dummies] >> Started: [ node1 node2] >> What I want to achieve is to take a middle dummy primitive out but leave >> the rest running. When I do that - for example on dummy3; dummies 4 and >> 5 also get taken out such that I am left with this: >> Clone Set: cl_dummies [grp_dummies] >> Resource Group: grp_dummies:0 >> dummy1:0 (ocf::pacemaker:Dummy): Started node1 >> dummy2:0 (ocf::pacemaker:Dummy): Started node1 >> dummy3:0 (ocf::pacemaker:Dummy): Stopped >> dummy4:0 (ocf::pacemaker:Dummy): Stopped >> dummy5:0 (ocf::pacemaker:Dummy): Stopped >> Resource Group: grp_dummies:1 >> dummy1:1 (ocf::pacemaker:Dummy): Started node2 >> dummy2:1 (ocf::pacemaker:Dummy): Started node2 >> dummy3:1 (ocf::pacemaker:Dummy): Stopped >> dummy4:1 (ocf::pacemaker:Dummy): Stopped >> dummy5:1 (ocf::pacemaker:Dummy): Stopped >> What I would like is this: >> Clone Set: cl_dummies [grp_dummies] >> Resource Group: grp_dummies:0 >> dummy1:0 (ocf::pacemaker:Dummy): Started node1 >> dummy2:0 (ocf::pacemaker:Dummy): Started node1 >> dummy3:0 (ocf::pacemaker:Dummy): Stopped >> dummy4:0 (ocf::pacemaker:Dummy): Started node1 >> dummy5:0 (ocf::pacemaker:Dummy): Started node1 >> Resource Group: grp_dummies:1 >> dummy1:1 (ocf::pacemaker:Dummy): Started node2 >> dummy2:1 (ocf::pacemaker:Dummy): Started node2 >> dummy3:1 (ocf::pacemaker:Dummy): Stopped >> dummy4:1 (ocf::pacemaker:Dummy): Started node2 >> dummy5:1 (ocf::pacemaker:Dummy): Started node2 >> A work around I have considered is to edit the group and resort the list >> so that the Filesystem primitive I'm interested in working on is named >> last but I wonder if I'll remember ;-) to do that the next time I need >> to perform maintenance. >> Or is there a better way to do this that I have not been introduced too >> yet? >> Regards, >> Nick > > It's already been discussed a couple times. > See > http://oss.clusterlabs.org/pipermail/pacemaker/2011-March/009435.html > and follow link/answers. > > -- > Cheers, > Florian Crouzat > > _______________________________________________ > 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 > _______________________________________________ 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
