From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Thu, 6 Aug 2009 09:04:51 -0500 Subject: [Cluster-devel] disallowed in cluster3 In-Reply-To: <4A7A8175.3010109@redhat.com> References: <20090805165234.GB17292@redhat.com> <4A7A8175.3010109@redhat.com> Message-ID: <20090806140451.GA15669@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. >groupd_compat="1"/> > >exists. > > > Thanks, I've been looking for an excuse to add code to cluster3 to > disable that mode ;-) > > I'm not happy with cman reading groupd tags out of cluster.conf though. > The alternatives are to have an extra tag for cman, but that risks users > only setting one or the other and causing havoc. So how about a higher > level flag ? Yeah, the group/groupd_compat is a little odd in that way... I have all my daemons checking for that one tag. cluster compat wouldn't be bad, or instead of a cluster attribute it could be a more generic element -- that would just mean changing into or something like that. With the release out, I think it's too late to remove group/groupd_compat, but we can add something new that supersedes it.