[PATCH] CTDB recovery lock with arbitrary cluster mutex

[Amitay Isaacs]

On Wed, Apr 27, 2016 at 8:14 PM, Martin Schwenke <martin at meltin.net> wrote:

> On Wed, 27 Apr 2016 07:47:16 +0200, Ralph Boehme <slow at samba.org> wrote:
>
> > On Tue, Apr 26, 2016 at 01:45:40PM +1000, Martin Schwenke wrote:
> > > [Resending from correct address...can moderators please drop the other
> one?]
> > >
> > > The attached patch set changes the CTDB recovery lock so that it can be
> > > implemented using an arbitrary, external cluster mutex helper.  At the
> > > configuration level this looks like:
> > >
> > >   CTDB_RECOVERY_LOCK="!/path/to/my/cluster/mutex/helper [arg ...]"
> > >
> > > Without the leading '!' CTDB continues to use the setting as the name
> > > of a recovery lock file, which is passes to the provided fcntl(2) lock
> > > helper.
> >
> > would it make sense to use a scheme similar to KRB5CCNAME? Eg
> >
> > CTDB_RECOVERY_LOCK="/path/to/file"
> > CTDB_RECOVERY_LOCK="FILE:/path/to/file"
> > CTDB_RECOVERY_LOCK="EXTERNAL:/path/to/external_program"
>
> We do that for CTDB_LOGGING, where we have 2 very different options...
> and the possibility of others in future.
>
> However, in this case I'm not not sure the extra verbosity would add
> anything.  I don't think the 2nd option of "FILE:" makes sense because
> it means there would be 2 ways of saying the same thing.  I really
> want to continue to allow a bare filename to be specified, partly
> because it is backward compatible and because I think that most people
> will use the default helper in the medium term.
>
> If I thought this was likely to be extended beyond the choice
> between the default and an arbitrary command string, then I think that a
> more general syntax would be useful.  At the moment I'm leaning towards
> brevity.
>
> If there are strong opinions then I'm happy to be convinced.  The code
> change would be small and the documentation is easy to update.
>
> peace & happiness,
> martin
>
>
I am in favour of keeping configuration file parsing to a minimum.  We can
always add more flexible configuration option, if is really required.

Pushed to autobuild.

Amitay.