Re: [RFC] quorum module configuration bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss


[Index of Archives]     [Linux Clusters]     [Corosync Project]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [X.Org]

  Powered by Linux