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? 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. > >> >>> But you'd need to add an other trigger on "dc-priority in configuration >>> changed", complicating this stuff for no reason. >>> >>>> We actually discussed node defaults a while back. Those would be >>>> similar to resource and op defaults which Pacemaker already has, and >>>> set defaults for node attributes for newly joined nodes. At the time >>>> the idea was to support putting new joiners in standby mode by >>>> default, so when you added a node in a symmetric cluster, you wouldn't >>>> need to be afraid that Pacemaker would shuffle resources around.[1] >>>> This dc-priority would be another possibly useful use case for this. >>> >>> Not so sure about that. >>> >>>> [1] Yes, semi-doable with putting the cluster into maintenance mode >>>> before firing up the new node, setting that node into standby, and >>>> then unsetting maintenance mode. But that's just an additional step >>>> that users can easily forget about. >>> >>> Why not simply add the node to the cib, and set it to standby, >>> before it even joins for the first time. >> >> Haha, good one. >> >> Wait, you weren't joking? >> >> Florian >> >> -- >> Need help with High Availability? >> http://www.hastexo.com/now >> >> _______________________________________________ >> 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 _______________________________________________ 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
