[PATCHES] make ctdb runnable in non-FHS installs
martin at meltin.net
Fri Jun 10 05:43:51 UTC 2016
On Thu, 9 Jun 2016 17:57:21 +0200, Michael Adam <obnox at samba.org> wrote:
> After a long fruitful IRC discussion with Martin
> and Amitay, we are sticking with #1, i.e. not renaming
> ctdb and naming the wrapper ctdb. This poses too many
> Instead the updated patchset first makes sure that
> the proper ctdb binary can always be found as $CTDB
> in the scripts (and is used in the scripts). For the
> tests, a simple CTDB=ctdb override did the trick.
The hunk in the last patch that does the wscript sed magic needs to
come into the first patch, so that "/usr/local/bin" gets substituted on
Can you please move the patch that sets CTDB in the test code to be
second in the series? That way it comes before the other patches that
use $CTDB in eventscripts, and that means that tests will pass for
each patch in the series.
In that patch it turns out I was wrong about needing something in
local_daemons.bash. This is already done in integration.bash,
which is used by "simple" and "complex" tests. Sorry I got that
wrong! For the hunk that remains, you could do the export on the same
line as the assignment, but that's no big deal... :-)
> Node: I provided patches to make use of $CTDB
> instead of verbatim 'ctdb' as one patch per file.
> I like this better, but if people insist, we could
> also squash those into one big sweeping change patch.
No worries... :-)
> Finally the super simple wrapper is provided
> as ctdb_wrapper. This is mainly convenient
> when a non-default CTDB_SOCKET is set in the conf file.
> Note: instead of doing the maybe_set thing to
> turn CTDB_SOCKET into a --socket option, we could
> use export CTDB_SOCKET, but I like cmdline options
> better and we don't need the export for other purposes.
Can we please drop the wrapper (and the maybe_set() refactoring) for
now, get the $CTDB stuff upstream and discuss the wrapper further?
Before I added all of the sed magic to make things install cleanly, I
thought about adding a wrapper... but I'm not sure it serves a useful
purpose anymore. For a regular installation CTDB_SOCKET should not be
set - the socket location should be set at compile time. For testing
with local daemons, the preference is to use onnode with
$CTDB_NODES_SOCKETS set, the way local_daemons.bash does it. This
provides a nice abstraction layer so tests can be written that can run
against both local daemons and a real cluster, like the "simple" tests.
If we have a wrapper then it will also need a manpage, since it is
installed in a bin directory.
Also, I honestly think it will confuse people and they won't know which
command to use...
> In the long run we may teach ctdb (and ctdbd) to
> properly parse a config file, and then get rid of
> the band-aid that ctdb_wrapper is.
I think this is in all of our long-term interests... :-)
peace & happiness,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the samba-technical