Hi All,
As we all know, our regression tests are killing us. An average, one
regression will take approximately two and half hours to complete the
run. So i guess this is the right time to think about enhancing our
regression.
Proposal 1:
Create a new option for the daemons to specify that it
On 8 May 2015, at 16:19, Jeff Darcy jda...@redhat.com wrote:
snip
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
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
On 8 May 2015, at 10:02, Mohammed Rafi K C rkavu...@redhat.com wrote:
Hi All,
As we all know, our regression tests are killing us. An average, one
regression will take approximately two and half hours to complete the
run. So i guess this is the right time to think about enhancing our
On 05/08/2015 08:54 PM, Justin Clift wrote:
On 8 May 2015, at 10:02, Mohammed Rafi K C rkavu...@redhat.com wrote:
Hi All,
As we all know, our regression tests are killing us. An average, one
regression will take approximately two and half hours to complete the
run. So i guess this is the
On 8 May 2015, at 18:41, Pranith Kumar Karampuri pkara...@redhat.com wrote:
snip
Break the regression tests into parts that can be run in parallel.
So, instead of the regression testing for a particular CR going from the
first test to the last in a serial sequence, we break it up into a
