On Fri, Jan 13, 2012 at 3:21 AM, David Teigland <teigland@xxxxxxxxxx> wrote: > 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. Its a free-for-all with a list too, since that list must also be modifiable at runtime. If you want to stop old nodes from coming back, change the authkey as Steve suggested (or port i guess). > > 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. Its a no brainer for me too, partly because I do it so often I have a script to do it automatically. But I agree with Chrissie "anything that reduces the amount of configuration a user has to do to get a cluster up and running is a GoodThing". Not everyone is a cluster developer and less steps means less to get wrong. > > 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. Also no, its because I mostly interact with people complaining how hard we make clustering. It would have been incredibly convenient for Pacemaker if corosync provided the full list of online and offline nodes like heartbeat, but it doesn't so we made Pacemaker smarter. > Maybe you have your own list of all > possible nodes in pacemaker. Right, we build one up over the life of the cluster. You /can/ pre-populate it, but we'll also push in whatever corosync tells us. People usually rely on the latter. _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
