From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Teigland <teigland@redhat.com>
Date: Mon, 22 Oct 2007 10:12:01 -0500
Subject: [Cluster-devel] spectator setting in cluster.conf
Message-ID: <20071022151200.GA26370@redhat.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I believe that all cluster.conf settings currently map to a specific
setting in one specific subsystem.  We now have a proposal to add an
abstract "spectator" setting that would be translated into multiple
lower-level, subsystem-specific settings.  It's not clear what the
cluster.conf syntax would look like, but it would need to be per-node.

Initially, there could be three specific results of this setting:

1. gfs_controld would read this and append the "spectator" mount option
   to all gfs mounts made by the node.  This causes gfs to not use a
   journal, and to never write to the disk (includes never doing
   recovery).

   The standard, lower-level mechanism for doing this (*without* the
   new setting in cluster.conf), is to add "spectator" to /etc/fstab
   entries.  We need to be careful when inventing specialized ways of
   doing things outside the standard practice.

2. /etc/init.d/cman would skip the 'fence_tool join' step for nodes
   with this setting.  Because gfs is guaranteed to never write to the
   fs, we can allow the node to mount without joining the fence domain.
   If the spectator node fails, it would not be fenced.

   The standard, low-level mechanism for doing this (without the new
   setting in cluster.conf) is to add a new option to the init-script's
   config file /etc/sysconfig/cman.

3. service_cman.lcrso (the cman openais plugin) would read this and
   assign the node 0 votes, so its membership wouldn't affect quorum.

   The standard way to do this would be to set votes="0" in the
   <clusternode/> entry.

In each case, the existence of the lower-level setting would override the
effect of the abstract spectator setting.

So, setting spectator for a node would be a shortcut for configuring the
three items above.  We may also decide to add other effects in other
subsystems.  Typically, this kind of abstraction is translated by a higher
layer of software, like conga.  But, this may be a case where the
abstraction is useful enough that it should be available to non-conga
users.  I don't have any preference in the matter and would be happy to
see it implemented in either layer.

Dave