[Pacemaker] [RFC] [Patch] DC node preferences (dc-priority)

[Lars Ellenberg]

On Mon, Jun 04, 2012 at 11:33:45AM +1000, Andrew Beekhof wrote:
> On Mon, Jun 4, 2012 at 11:28 AM, Andrew Beekhof <andrew at beekhof.net> wrote:
> > On Fri, May 25, 2012 at 7:48 PM, Florian Haas <florian at hastexo.com> wrote:
> >> On Fri, May 25, 2012 at 11:38 AM, Lars Ellenberg
> >> <lars.ellenberg at linbit.com> wrote:
> >>> On Fri, May 25, 2012 at 11:15:32AM +0200, Florian Haas wrote:
> >>>> On Fri, May 25, 2012 at 10:45 AM, Lars Ellenberg
> >>>> <lars.ellenberg at linbit.com> wrote:
> >>>> > Sorry, sent to early.
> >>>> >
> >>>> > That would not catch the case of cluster partitions joining,
> >>>> > only the pacemaker startup with fully connected cluster communication
> >>>> > already up.
> >>>> >
> >>>> > I thought about a dc-priority default of 100,
> >>>> > and only triggering a re-election if I am DC,
> >>>> > my dc-priority is < 50, and I see a node joining.
> >>>>
> >>>> Hardcoded arbitrary defaults aren't that much fun. "You can use any
> >>>> number, but 100 is the magic threshold" is something I wouldn't want
> >>>> to explain to people over and over again.
> >>>
> >>> Then don't ;-)
> >>>
> >>> Not helping, and irrelevant to this case.
> >>>
> >>> Besides that was an example.
> >>> Easily possible: move the "I want to lose" vs "I want to win"
> >>> magic number to be 0, and allow both positive and negative priorities.
> >>> You get to decide whether positive or negative is the "I'd rather lose"
> >>> side. Want to make that configurable as well? Right.
> >>
> >> Nope, 0 is used as a threshold value in Pacemaker all over the place.
> >> So allowing both positive and negative priorities and making 0 the
> >> default sounds perfectly sane to me.
> >>
> >>> I don't think this can be made part of the cib configuration,
> >>> DC election takes place before cibs are resynced, so if you have
> >>> diverging cibs, you possibly end up with a never ending election?
> >>>
> >>> Then maybe the election is stable enough,
> >>> even after this change to the algorithm.
> >>
> >> Andrew?
> >
> > Probably.  The preferences are not going to be rapidly changing, so
> > there is no reason to suspect it would destabilise things.
> 
> Oh, you mean if the values are stored in the CIB?
> Yeah, I guess you could have issues if you changed the CIB during a
> cluster partition... dont do that?

Right. That was my concern.
So I'd rather not add them to the cib,
but get them from environment variables.
Which means that I would need to restart the local stack, if I wanted
to change the preference. Good enough.

> Honestly though, given the number (1? 2? 0?) of sites in the world
> that actually need this, my main criteria for a successful patch is
> "not screwing it up for everyone else".
> Which certainly rules out starting elections just because someone
> joined.  Although "i've just started and have a non-zero preference so
> I'm going to force an election" would be fine.

Thanks.
I'll see what the current status of that patch is, and if we can prepare
a patch to be considered for upstream inclusion.
May take a while though, due to round trip times ;-)


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com