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

[Andrew Beekhof]

On Mon, Jun 4, 2012 at 11:28 AM, Andrew Beekhof <andrew at beekhof.net> wrote:
> 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.

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