On 2009-09-16 13:29, Dejan Muhamedagic wrote: > Hi Florian, > > On Wed, Sep 16, 2009 at 08:25:30AM +0200, Florian Haas wrote: >> Lars, Dejan, >> >> as discussed on #linux-ha yesterday, I've pushed a small changeset to >> the Filesystem RA that implements a monitor operation which checks >> whether I/O on the mounted filesystem is in fact possible. Any >> suggestions for improvement would be most welcome. > > IMO, the monitor operation is now difficult to understand. I > don't mean the code, I didn't take a look at the code yet, but > the usage. Also, as soon as you set the statusfile_prefix > parameter, the 0 depth monitor changes behaviour. I don't find > that good. The basic monitor operation should remain the same and > just test if the filesystem is mounted as it always used to.
I thought it was fairly straightforward the way it's implemented, but
then of course I'm no impartial judge. :) I can change it so that if
depth=0 (the default), and statusfile_prefix is set, then
statusfile_prefix is effectively ignored. Which I believe isn't
intuitive. And it would also mean that "depth" (i.e. $OCF_CHECK_LEVEL)
suddenly affects start and stop, which isn't exactly straightforward either.
> The new parameter should influence only the monitor operations of
> higher (deeper :) depth. So, I'd propose to have two depths, say
> 10 and 20, of which the first would be just the read test and the
> second read-write.
Is there any convention on what granularity "depth" uses? The other RAs
that use it (IPaddr and mysql, AFAICT) only distinguish between zero and
nonzero.
> Finally, the statusfile_prefix should be optional for deeper
> monitor operations and default to .${OCF_RESOURCE_INSTANCE}. If
> OCF_RESOURCE_INSTANCE doesn't contain the clone instance, then we
> should append the clone instance number (I suppose that it's
> available somewhere).
It does. I just thought it would be helpful to see the node name in there.
And, I deliberately used an empty default to employ my "omit monitoring
in case statusfile_prefix is unset" logic. Which has its pros and cons,
as stated above.
I'm not at all unwilling to change the agent if others agree that your
suggestions should be implemented, but I'd like to hear some more thoughts.
Cheers,
Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
