[Gluster-devel] Proposal for improving throughput for regression test
Jeff Darcy
jdarcy at redhat.com
Fri May 8 15:19:18 UTC 2015
> Proposal 1:
>
> Create a new option for the daemons to specify that it is running as
> test mode, then we can skip fsync calls used for data durability.
Alternatively, run tests with the relevant directories (bricks and
/var/lib stuff) in ramdisks. No code change needed, but some tests
might need to be resized to read/write less data (probably a good
idea anyway). FWIW, I already do this for tests I run myself.
> Proposal 2:
>
> Use ip address instead of host name, because it takes some good amount
> of time to resolve from host name, and even some times causes spurious
> failure.
If resolution is taking a long time, that's probably fixable in the
test machine configuration. Reading a few lines from /etc/hosts should
take only a trivial amount of time.
> Proposal 3:
> Each component has a lot of .t files and there is redundancy in tests,
> We can do a rework to reduce the .t files and make less number of tests
> that covers unit testing for a component , and run regression runs once
> in a day (nightly) .
I wouldn't favor a general reduction of tests so much as a reduction
(and reordering) of which ones get run for a particular change. For
example, if a patch is to AFR then it's most likely to fail in an AFR
test so we should run those first. On the flip side, it's unlikely to
fail in an SSL test, so maybe we don't need to run those at all
(except nightly). If we had a "map" of which tests are most relevant
to which pieces of code, we could automate the process of deciding
which tests to run first, which to run second, and which to skip
altogether, all on a per-patch basis.
More information about the Gluster-devel
mailing list