All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] disallowed in cluster3
Date: Wed, 12 Aug 2009 16:48:10 -0500	[thread overview]
Message-ID: <20090812214810.GF7564@redhat.com> (raw)
In-Reply-To: <4A7A8175.3010109@redhat.com>

On Thu, Aug 06, 2009 at 08:08:37AM +0100, Christine Caulfield wrote:
> On 05/08/09 17:52, David Teigland wrote:
> >When rewriting daemons for cluster3 to remove groupd, I wrote them to not 
> >need
> >or use the disallowed-nodes feature from cman for handling remerging of
> >cluster partitions.  In compat mode, however, (the cluster2 code) they 
> >would
> >still depend on that cman feature, which is why it still exists in cluster3
> >cman.
> >
> >I've found, though, that when we do have a partition remerge, cman's
> >disallowed feature gets in the way of the daemons trying to handle it
> >themselves (which I'm testing, it doesn't seem quite right in all
> >partitioning/merging cases yet.)
> >
> >So, I think what we need is for cluster3 cman to turn off the disallowed
> >feature unless the cluster is in compat mode, i.e.<group 
> >groupd_compat="1"/>
> >exists.
> 
> 
> Thanks, I've been looking for an excuse to add code to cluster3 to 
> disable that mode ;-)

Trying this out and testing the daemon's handling of partition merging
situations...  I uncovered one of my own comments in fenced:

/* We don't require cman dirty/disallowed to detect and handle cpg merges
after a partition, because we already do that with started_count checks and
our own disallowed flag.  But, we do need cman dirty/disallowed to deal with
correctly skipping victims that rejoin the cluster.  Without cman
dirty/disallowed, we'd skip fencing a node after a merge of a partition since
the merged node would be a cman member and a fenced:daemon cpg member.  By
setting the dirty flag, cman won't report a dirty merged node as a member, so
we'll continue fencing it. */

So, the primary reason for cman disallowed is gone, but I'd forgotten about
this little unsolved detail around bypassing fencing of a node that has
rebooted and rejoined (distinguishing that from partitioned and rejoined).
There really should be a way for fenced to deal with that without punting it
off to cman disallowed, I'll be working on that.

Dave



      parent reply	other threads:[~2009-08-12 21:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-05 16:52 [Cluster-devel] disallowed in cluster3 David Teigland
2009-08-06  7:08 ` Christine Caulfield
2009-08-06 14:04   ` David Teigland
2009-08-06 17:39   ` Fabio M. Di Nitto
2009-08-12 21:48   ` David Teigland [this message]

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=20090812214810.GF7564@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.