Re: vstart runner for cephfs tests

[John Spray <john.spray@redhat.com>]

On 23/07/15 12:23, Loic Dachary wrote:
> You may be interested by
>
> https://github.com/ceph/ceph/blob/master/src/test/ceph-disk-root.sh
>
> which is conditionally included
>
> https://github.com/ceph/ceph/blob/master/src/test/Makefile.am#L86
>
> by --enable-root-make-check
>
> https://github.com/ceph/ceph/blob/master/configure.ac#L414
>
> If you're reckless and trust the tests not to break (a crazy proposition by definition IMHO ;-), you can
>
> make TESTS=test/ceph-disk-root.sh check
>
> If you want protection, you do the same in a docker container with
>
> test/docker-test.sh --os-type centos --os-version 7 --dev make TESTS=test/ceph-disk-root.sh check
>
> I tried various strategies to make tests requiring root access more accessible and less scary and that's the best compromise I found. test/docker-test.sh is what the make check bot uses.

Interesting, I didn't realise we already had root-ish tests in there.

At some stage the need for root may go away in ceph-fuse, as in 
principle fuse mount/unmounts shouldn't require root.  If not then 
putting an outer docker wrapper around this could make sense, if we 
publish the built binaries into the docker container via a volume or 
somesuch.  I am behind on familiarizing myself with the dockerised tests.

> When a test can be used both from sources and from teuthology, I found it more convenient to have it in the qa/workunits directory which is available in both environments. Who knows, maybe you will want a vstart based cephfs test to run as part of make check, in the same way
>
> https://github.com/ceph/ceph/blob/master/src/test/cephtool-test-mds.sh
>
> does.

Yes, this crossed my mind.  At the moment, even many of the "quick" 
tests/cephfs tests take tens of seconds, so they are probably a bit too 
big to go in a default make check, but for some of the really simple 
things that are currently done in cephtool/test.sh, I would be temped to 
move them into the python world to make them a bit less fiddly.

The test location is a bit challenging, because we essentially have two 
not-completely-stable interfaces here, vstart and teuthology. Because 
teuthology is the more complicated, for the moment it makes sense for 
the tests to live in that git repo.  Long term it would be nice if 
fine-grained functional tests lived in the same git repo as the code 
they're testing, but I don't really have a plan for that right now 
outside of the probably-too-radical step of merging ceph-qa-suite into 
the ceph repo.

John