[Pacemaker] Shouldn't colocation -inf: be mandatory?

Dejan Muhamedagic dejanmm at fastmail.fm
Tue Jun 15 15:41:57 EDT 2010


On Tue, Jun 15, 2010 at 01:50:06PM +0200, Andrew Beekhof wrote:
> On Tue, Jun 15, 2010 at 1:38 PM, Vadym Chepkov <vchepkov at 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.kurz at 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 <vchepkov at 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 at 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




More information about the Pacemaker mailing list