Hi Florian,
This discussion digressed, and I'm not entirely happy with the
current user interface/implementation. Do you intend to do
something about it?
Cheers,
Dejan
On Wed, Sep 16, 2009 at 02:41:35PM +0200, Dejan Muhamedagic wrote:
> Hi,
>
> On Wed, Sep 16, 2009 at 02:08:06PM +0200, Florian Haas wrote:
> > 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 statusfile_prefix parameter should not affect the basic
> monitor operation. I think that if it does that will be source of
> confusion.
>
> > > 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.
>
> Not sure, but I don't think so. I think it's up to the RA to
> interpret it at will. At any rate, multiple depths may be
> supported.
>
> > > 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.
>
> You can then set the default to: .`uname`.${OCF_RESOURCE_INSTANCE}.
> I think it's good that it starts with '.' because it's of no
> importance to the normal users. Perhaps we could also reserve a
> directory named say .OCF_Filesystem_monitor/. I doubt that that
> name would collide with normal users.
>
> > 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.
>
> I'm willing to hear other comments, of course, but please note
> that this is not about democracy :)
>
> Cheers,
>
> Dejan
>
> > Cheers,
> > Florian
> >
>
>
>
> > _______________________________________________________
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
