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

[Lars Ellenberg]

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.

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.

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.

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