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?
This whole thread makes me want to hurt kittens. > >> 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