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

[Andrew Beekhof]

On Fri, May 25, 2012 at 7:48 PM, Florian Haas <florian at hastexo.com> wrote:
> On Fri, May 25, 2012 at 11:38 AM, Lars Ellenberg
> <lars.ellenberg at 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.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.
>
> 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.

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