Re: [RFC] quorum module configuration bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 01/24/2012 09:09 PM, Vladislav Bogdanov wrote:
> 24.01.2012 19:10, Fabio M. Di Nitto wrote:
> [snip]
>>> If I power on more "unseen" nodes, expected_votes is automatically
>>> incremented and saved into CIB. If I then power down that nodes, their
>>> votes are still considered until I remove them from CIB and decrement
>>> expected_votes manually (actually that part didn't fully work last time
>>> I checked).
>> You can do this with votequorum already. New nodes are added to the list
>> and expected_votes increases automagically. On removal, you will need to
>> manually decrement expected_votes as you do now pretty much.
> BTW, is it now possible to alter nodelist at runtime (remove some nodes
> from there)? It is kinda problematic with flatiron.

I believe so, but Honza has been working on that portion of the code and
should be able to answer details better. The quorum module itself tracks
changes in that list and recalculate etc.

>>> And I do not like idea of touching configuration file every time I want
>>> to add node to cluster. And then re-distributing that config over all
>>> nodes, and then reload it on every node.
>>> Now I have all 17 nodes listed in corosync.conf (UDPU), but my
>>> expected_votes in pacemaker CIB is 3. That's why Steve's idea of
>>> calculating expected_votes from a vote-list would be a regression for me.
>> Ok, I´ll make it happen by allow expected_votes: XX overrides the
>> calculated one from the nodelist.
>> You will be able to change expected_votes at runtime if necessary (up or
>> down) and new "seen" nodes will automatically increase the expected_votes.
> Do I need to do it on every node or just on one?

Just one and the change is propagated to all nodes.

> And, it should not be allowed to set it lower than number of votes from
> currently active nodes.
> Probably even not lower than number of votes from nodes which are now
> either active or inactive but joined at least once (I suppose that
> nodelist is fully editable at runtime, so admin may some-how reset join
> count of node and only than reduce expected_votes).

Hmmm I will need to check explicitly on what the code does if you try to
set it lower than active nodes (I didn't write all the code FYI), but
IIRC you can't really set it lower.

As for blocking it even further down, that might be problematic when
used in combination with expected_votes override and removing nodes.

Since this override feature has been approved only yesterday, I'll need
a few days to look into the corner cases and gotchas. Mostly we need to
make sure we don't introduce windows for total breakage :)

discuss mailing list

[Corosync Project]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux