[PATCH] CTDB recovery lock with arbitrary cluster mutex
amitay at gmail.com
Thu Apr 28 08:36:50 UTC 2016
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
> > >
> > > 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
> 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,
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.
More information about the samba-technical