Dne 25.1.2012 06:19, Fabio M. Di Nitto napsal(a):
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.
Ya, it's perfectly possible. Just create nodelist.node.X.ring0_addr, where X is even nonexisting number for adding new node, or existing for change the node (doesn't work for local node, because we are not supporting rebind of socket yet). You can also (for example) alter number of votes by setting nodelist.node.X.quorum_votes.
So let's give example: - Let's add node with address 192.168.1.5 corosync-cmapctl -s nodelist.node.5.ring0_addr str 192.168.1.5 Corosync log should show something like (in debug mode): adding dynamic member 192.168.1.5 for ring 0 - Now let's change newly added node number of votes: corosync-cmapctl -s nodelist.node.5.quorum_votes u32 3 - And now remove node: corosync-cmapctl -d nodelist.node.5.ring0_addr Honza
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 :) Fabio
_______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss