On Mon, Jun 04, 2012 at 11:33:45AM +1000, Andrew Beekhof wrote: > On Mon, Jun 4, 2012 at 11:28 AM, Andrew Beekhof <and...@beekhof.net> wrote: > > On Fri, May 25, 2012 at 7:48 PM, Florian Haas <flor...@hastexo.com> wrote: > >> On Fri, May 25, 2012 at 11:38 AM, Lars Ellenberg > >> <lars.ellenb...@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.ellenb...@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 _______________________________________________ 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
