On 1/25/2012 6:19 AM, Fabio M. Di Nitto wrote: >>>> >>>> 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. > I also verified this condition. One node propagates to all. >> >> And, it should not be allowed to set it lower than number of votes from >> currently active nodes. This is how it already works. If you issue the command asking for expected_votes < number_of_active_nodes, you get ev = number_of_active_node. >> 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). I have been thinking about this some more, but I am not sure I grasp the use case or what kind of protection you try to suggest. Reducing the number of expected_votes is an admin action, it´s not very different from removing a node from the "seen" list manually and recalculating expected_votes. Can you clarify it for me? Fabio _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
