From mboxrd@z Thu Jan  1 00:00:00 1970
From: Charles Riley <criley@erad.com>
Date: Mon, 15 Sep 2008 10:33:56 -0400
Subject: [Cluster-devel] Change in rgmanager - broke my config
Message-ID: <48CE7254.4000401@erad.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

Hi,

I am using rhcs on RHEL4.

At some point in the recent past, clurgmgrd was changed so that when it
parses cluster.conf,  it checks to make sure that filesystem mountpoints
are all unique.

For 99% of clusters out there this is probably a good thing.  However,
in this case failover domains and services are configured such that even
though multiple machines are mounting devices on the same mount point,
there is no possible way that any one server could ever attempt to mount
more than one device on the same mountpoint.  Each server runs ONE
service which gets it's own private disk space (no filesystem sharing is
going on, and "run exlclusive" is enabled for the service).  If one of
the hot standby servers in the failover domain for the service isn't
available ( extremely small but non-zero chance of that happening),  the
service simply won't (shouldn't) start.

In short, rgmanager is being overprotective and hosing me up =).

I could just use older rpms, but looking through the release notes there
are several bugs fixed, and I don't really want to lose those fixes.

What I'd like to do is modify rgmanager so it will not enforce that
filesystem mountpoints be unique in a case like mine.

I'm in a bit of a crunch (I need to get a system configured, tested, 
and shipped) so if anyone is familiar with what section of the code I
should be looking at I'd appreciate the headstart =)

Also, it appears that once rgmanager finds a collision, it pretty much
just stops parsing that section of the config.  One side effect of that
is that the system will then let you start that service and report the
service running,  even though it's really not.  Not really a bug, but
probably not how we'd like it to work.

Thanks guys,

Charles