[PATCHSET] enable ctdb's selftest in autobuild

[Michael Adam]

On 2013-11-27 at 20:33 +1100, Amitay Isaacs wrote:
> On Wed, Nov 27, 2013 at 8:22 PM, Michael Adam <obnox at samba.org> wrote:
> 
> > Comments on the list after a long irc discussions:
> >
> > On 2013-11-27 at 17:25 +1100, Martin Schwenke wrote:
> > > Hi Michael,
> > >
> > > On Mon, 25 Nov 2013 17:21:37 +0100, Michael Adam <obnox at samba.org>
> > > wrote:
> > >
> > > > attached is a patchset, I have been pair- and
> > > > ping-pong-programming with Martin and Amitay during
> > > > the last week or so.
> > > >
> > > > It enables ctdb selftest in samba's autobuild.
> > >
> > > A couple of things:
> > >
> > > * Sorry, my suggestion to use $TEST_VAR_DIR was bogus.  It works with
> > >   local daemons (so helps in autobuild) but doesn't work when you run
> > >   the tests on a cluster because $TEST_VAR_DIR doesn't exist on the
> > >   cluster nodes.
> > >
> > >   This patch:
> > >
> > >     ctdb:tests: use TEST_VAR_DIR instead of /tmp in integration.bash
> > >
> > >   can be dropped for now because the functionality is only used in
> > >   "complex" tests, which need a cluster to run on.  So, we don't need
> > >   this for autobuild.
> >
> > Ok, we can do this for now, but it is not very robust. :-)
> >
> 
> Just changing /tmp to $TEST_VAR_DIR is incorrect since those directories
> need to exist on the cluster nodes.

Well, what I meant is that, right, I see that the functions
I changed are currently only used in the 31_nfstickle test,
which is not run in autotest. So it is safe now to leave it
at /tmp. But this is not robust in the sense the one might
start to use that function in other tests and then create
problems with concurrent test runs. More robust in my
sense would be to use a TMP_DIR variable (or similar) that
is set to /tmp or to "$TEST_VAR_DIR" depending on whehter
we run agains local daemons or against a real cluster.
That's what I meant.

> So it's not just question of being robust.
> Martin has thought of a better solution that does not require
> messing around with temporary files and it's much cleaner.

Sure that would even be better.

> > As discussed, I would like to split up integration.bash
> > so that is becomes more obvious which parts are used where.
> >
> The integration tests from "simple" test suite can actually run both on a
> single machine (using local daemons) and on a cluster.  So it's not quite
> easy to split that functionality.

Yes, some parts can be split out easily and shouldn't be in this
file. For instance there are a couple of functions in "integration.bash"
that are taking care of starting and stopping local daemons, etc.
These are useing TEST_VAR_DIR, and correctly so.
I will move these into a different shell fragment.

> However, any infrastructure required for
> "complex" test suite can definitely be separated as those tests can only
> run on a real cluster.

Right, this is at the other extreme.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 215 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20131127/1c4e3aea/attachment.pgp>