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? > 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