On Thu, Jan 12, 2012 at 3:21 AM, David Teigland <teigland@xxxxxxxxxx> wrote: >> I much prefer the expected_votes field to any enumeration of the nodes. > > Expect admins to keep track of what expected_votes should be? No. Have corosync do it automatically. The quorum code knows how many nodes it has seen and how many votes they had. expected_votes is already updated internally if the current number is greater than what was configured, I'm only suggesting that it also be recorded on disk. I don't see any reason to involve the admin at all. > That sounds nearly impossible to do correctly. > >> Does anyone need the list of nodes to be preconfigured? > > The alternative would be trying to remember what they all are? Why do you need to if expected votes is set correctly? > Defining the set of nodes that compose the cluster seems like > a very good thing just for its own sake. On the otherhand, I'd argue that forcing people to run corosync-quorumtool and to then re-add the same information to the config with an editor, on every existing node, when adding a new member is inherently error prone. >> The only use-case I've heard so far was unicast, but even then why duplicate >> the list in the quorum block? > > The set of possible nodes is a fundamental requirement for doing quorum > correctly. Counting them up in your head and writing down the result as > expected_votes just obfuscates it. I wasn't suggesting that. > > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
