On Thu, Jan 12, 2012 at 04:50:44PM +1100, Andrew Beekhof wrote: > > 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. > > Surely a gfs2 partition can be mounted from nodes that were unknown > when it was formatted? The point is that I don't know who might come along and try to mount my file system next! It's a free-for-all without a list of allowed nodes. Maybe that's an important point that we've not drawn out yet. The list of nodes also operates as a "permission list". Any node that's not listed cannot join the cluster. I don't need to worry about some random or old node coming along and intruding. > I don't know about cman being in the "static list" either since it > also allowed nodes to be dynamically added at runtime. > > So I think its an artificial distinction, everyone needs a list of its peers. > Where we seem to disagree is how that list is constructed. > > You want it configured manually, and I think we should automate it. > We already have the details, we all make the necessary adjustments > when a new peer appears, why force the user to write it down too? Writing down a list of nodes is such a no brainer to me, that I was searching for a reason why it's not for you. I guess my two views explanation didn't really work out, which leaves me still puzzled. Maybe it's because you generally interact with the cluster at the pacemaker level, whereas I'm always interacting with the cluster at the corosync/cman level. Maybe you have your own list of all possible nodes in pacemaker. _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
