On Wed, Jan 11, 2012 at 11:21:59AM -0500, David Teigland 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? > 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? > Defining the set of nodes that compose the cluster seems like > a very good thing just for its own sake. I guess that's just one view. There really are two legitimate styles of assembling a cluster that we're trying to merge. In the first, you have a conceptual view of just a big pool nodes, more or less anonymous. They are just "workers", which higher level software (e.g. pacemaker) can use as needed to run things. The second is a more fixed, static approach. You start with with some specific nodes and you want to access some shared resource from those nodes. Because the resource is shared, there needs to be clustering involved to access it. e.g. this node needs to mount that gfs2 file system. The first view has historically been taken by corosync and pacemaker, and the second by cman/gfs2. Folks with the first view would think of a static node list as unnecessary, whereas it's the starting point in the second view. Anyway, I think that explains the disconnect. Getting back to the real question of what needs a node list, quorum is the only thing I can think of. _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
