On Tue, Jun 15, 2010 at 01:50:06PM +0200, Andrew Beekhof wrote: > On Tue, Jun 15, 2010 at 1:38 PM, Vadym Chepkov <vchep...@gmail.com> wrote: > > > > On Jun 15, 2010, at 4:57 AM, Andrew Beekhof wrote: > > > >> On Tue, Jun 15, 2010 at 10:23 AM, Andreas Kurz <andreas.k...@linbit.com> > >> wrote: > >>> On Tuesday 15 June 2010 08:40:58 Andrew Beekhof wrote: > >>>> On Mon, Jun 14, 2010 at 4:22 PM, Vadym Chepkov <vchep...@gmail.com> > >>>> wrote: > >>>>> On Jun 7, 2010, at 8:04 AM, Vadym Chepkov wrote: > >>>>>> I filed bug 2435, glad to hear "it's not me" > >>>>> > >>>>> Andrew closed this bug > >>>>> (http://developerbugs.linux-foundation.org/show_bug.cgi?id=2435) as > >>>>> resolved, but I respectfully disagree. > >>>>> > >>>>> I will try to explain a problem again in this list. > >>>>> > >>>>> lets assume you want to have several resources running on the same node. > >>>>> They are independent, so if one is going down, others shouldn't be > >>>>> stopped. You would do this by using a resource set, like this: > >>>>> > >>>>> primitive dummy1 ocf:pacemaker:Dummy > >>>>> primitive dummy2 ocf:pacemaker:Dummy > >>>>> primitive dummy3 ocf:pacemaker:Dummy > >>>>> colocation together inf: ( dummy1 dummy2 dummy3 ) > >>>>> > >>>>> and I expect them to run on the same host, but they are not and I > >>>>> attached hb_report to the case to prove it. > >>>>> > >>>>> Andrew closed it with the comment "Thats because you have > >>>>> sequential="false" for the colocation set." But sequential="false" means > >>>>> doesn't matter what order do they start. > >>>> > >>>> No. Thats not what it means. > >>>> And I believe I should know. > >>>> > >>>> It means that the members of the set are NOT collocated with each > >>>> other, only with any preceding set. > >>> > >>> Just for clarification: > >>> > >>> colocation together inf: ( dummy1 dummy2 dummy3 ) dummy4 > >>> > >>> .... is a shortcut for: > >>> > >>> colocation together1 inf: dummy4 dummy1 > >>> colocation together1 inf: dummy4 dummy2 > >>> colocation together1 inf: dummy4 dummy3 > >>> > >>> ... is that correct? > >> > >> Only if sequential != false. > >> For some reason the shell appears to be setting that by default. > >> > >>> > >>> To pick up Vadym's Question: > >>> > >>> * what would be the correct syntax to say > >>> "run-together-but-dont-care-if-one- > >>> dies-or-is-not-runable"? > >> > >> Choose a score < inf, just like regular colocation constraints. > > > > Ah, ok, thanks, I guess in my mind anything less then inf was "advisory". > > They are. > > Advisory is the only way to deal with the > "but-dont-care-if-one-dies-or-is-not-runable" part. > > > As long as I keep it above any resource-stickiness it should be in fact > > mandatory, right? > > Or something else needs to be taken to consideration? > > > > On a side note, I was trying to figure out how to make a set from two > > resources, so I just added a proper xml and checked what crm shell say > > about it. And it shows it like this: > > > > colocation together 5000: _rsc_set_ dummy1 dummy2 > > Strange. Dejan?
That's the way shell deals with a set which became 2-resource constraint because otherwise it wouldn't be able to make a difference between a set and a regular constraint. By removing the word "_rsc_set_" it would become a normal constraint. > > Who knew? I didn't see it anywhere in documentation. Forgot to add that in the documentation. > > Anyway, just so I get it right, what would be the opposite constraint > > (which is what this thread started from) > > If I want to have same dummy1, dummy2, dummy3 resources, but I don't want > > any of them ever to run simultaneously on the same host. What wold be the > > proper anti-colocation constraint for this configuration? > > Score = -inf, plus the patch, plus sequential = true (or unset). > Not sure how that looks in shell syntax though. colocation not-together -inf: d1 d2 d3 Thanks, Dejan > _______________________________________________ > 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker _______________________________________________ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
