On 01/12/2012 11:17 AM, David Teigland wrote: > On Thu, Jan 12, 2012 at 06:57:43PM +0100, Fabio M. Di Nitto wrote: >> On 01/12/2012 05:21 PM, David Teigland 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! >> >> Yeah but why does it matter? before the node can mount, it needs to join >> the cluster and be quorate. By that time you know who is in the membership. > > I want to know and control who will join the cluster. I don't care about > quorum or point-in-time membership here. > >>> It's a free-for-all without a list of allowed nodes. >> >> I think i can understand your use case here, but my question is why is >> quorum in charge of that? > > My point here is not about quorum (although this helps us when we do talk > about quorum.) This is just about defining what the cluster is. > >> Remember that this is not cman and that cman >> had 2 functions, one of membership management (that's the one you are >> really looking for, by allow/disallow a node) and quorum (calculated >> after membership management has kicked in). > > Right, both are important. > >>> 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. >> >> If anything, this has to happen either before quorum (at totem level or >> in between), or at a much higher level (application that care do it >> basically) since corosync doesn't really care, nor does pacemaker or the >> quorum module. > > I'm trying to make the argument that a node list is a good thing by > itself, apart from the benefits it has for quorum. > > With a node list, corosync *should* care about it, and should fail to > start on a node if that node cannot find itself in the node list. Also, > if a node does start, the other nodes should reject it if the joining node > is not in *their* node list (can happen if the joining node has an old > copy of the node list and has since been removed.) > > This is basic but important stuff that's been in cman for years, and it's > easy to take it for granted. > The authkey serves this purpose. If you have concerns that old nodes (or others) that have a copy of the auth key will join, then you should be changing the auth key on the existing cluster when permanently removing a node in any regard (since the auth key has now leaked into a re-purposed machine). Regards -steve > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
