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

Dejan Muhamedagic dejanmm at fastmail.fm
Tue Jun 15 19:34:47 UTC 2010


On Tue, Jun 15, 2010 at 12:56:11PM +0200, Andrew Beekhof wrote:
> On Tue, Jun 15, 2010 at 12:39 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> > On Tue, Jun 15, 2010 at 12:30:45PM +0200, Andrew Beekhof wrote:
> >> On Tue, Jun 15, 2010 at 12:14 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> >> > Hi,
> >> >
> >> > On Tue, Jun 15, 2010 at 10:57:47AM +0200, 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.
> >> >
> >> > You wanted to say "sequential == false"?
> >>
> >> no.
> >>
> >> !=
> >> ne
> >> not equal to
> >
> > Hmm, just checked in the Conf explained, on p.47 of the copy I
> > have here it says the other way. Or I don't understand the matter
> > either.
> >
> >> >> For some reason the shell appears to be setting that by default.
> >> >
> >> > This is sequential == false:
> >> >
> >> > colocation together inf: ( dummy1 dummy2 dummy3 ) dummy4
> >> >
> >> > This is sequential == true:
> >> >
> >> > colocation together inf: dummy1 dummy2 dummy3 dummy4
> >>
> >> How do you say that 1-3 are in one sequential set and 4 is in a different set?
> >
> > No way. Make two sets perhaps?
> 
> 
> Right.  How does one do that?
> 
> To me, ( a b c ) would have been the obvious syntax for defining a set.
> Not for setting sequential=false.

I didn't think that there would be a need for having two
sequential sets in a single constraint. We can make a delimiter
between sets if that's needed.

Thanks,

Dejan




More information about the Pacemaker mailing list