cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] spectator setting in cluster.conf
Date: Mon, 22 Oct 2007 10:12:01 -0500	[thread overview]
Message-ID: <20071022151200.GA26370@redhat.com> (raw)

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



             reply	other threads:[~2007-10-22 15:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-22 15:12 David Teigland [this message]
2007-10-23  5:25 ` [Cluster-devel] spectator setting in cluster.conf Fabio Massimo Di Nitto
2007-10-23 13:45   ` David Teigland
2007-10-23 16:58     ` Fabio Massimo Di Nitto
2007-10-23 18:15       ` David Teigland
2007-10-23 21:07         ` Fabio Massimo Di Nitto
2007-10-24  3:37     ` Fabio Massimo Di Nitto
2007-10-24  6:36       ` Fabio Massimo Di Nitto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071022151200.GA26370@redhat.com \
    --to=teigland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).