Jump to: navigation, search

Difference between revisions of "Blueprint-speed-up-tempest"

 
(10 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
== Summary ==
 
== Summary ==
  
Ruining test cases in parallel.
+
Use a horizontally and vertically scalable and extensible test runner.
  
 
== Release Note ==
 
== Release Note ==
Line 11: Line 11:
 
== Rationale ==
 
== Rationale ==
  
 +
The gate time has impact to the development speed.
 
Parallel test case execution on multiple machines can dramatically speed up Unit Test execution.
 
Parallel test case execution on multiple machines can dramatically speed up Unit Test execution.
 
=== Introduction ===
 
 
  
 
== User stories ==
 
== User stories ==
  
'Gate is tooo slow'
+
* 'Gate is tooo slow'
 +
* 'I would like use the same test runner with all OpenStack component and handling the test runs in similar way'
 +
* http://refstack.org/
  
 
== Assumptions ==
 
== Assumptions ==
  
Gate jobs will speed up.
+
* Happier developers.
 +
* Faster user level API validation
  
 
== Design ==
 
== Design ==
  
Replacing the notesttests test runner to testtools/testresources/testrepository combination.
+
* Replacing the notesttests test runner to testtools/testresources/testrepository combination.
 +
* Mitigate the common fixture usage
 +
* Maintain test capability without admin rights
  
 
== Implementation ==
 
== Implementation ==
  
Step one is to encapsulate the setUpClass() _contents_ into fixtures.
+
# Increase the single thread risks in order to be less confuse-able with parallel issues.  
Then, the body of the setUpClass should only contain calls to
+
The tempest code uses waits for delete  to mitigate the chance of running out from resources, this type of issue will happen in parallel.
instantiate the fixtures. If the tests are run via nosetests as
+
# fix numbered, order dependent issues
currently, there will be no operational changes and this can be landed
+
# traceable logging ??
in master.
+
# add an option to old and new code path
 +
# scale horizontally
 +
# Add test case scheduler which supports resource reuse
  
Step two is to start removing dependencies between the tests. This is
 
straight forward: for test in `testr list-tests` ; do testr run $test ;
 
done - repeat and fix issues until it works. Each test fix here can be
 
landed individually, as it's largely going to be a matter of adding
 
addCleanup calls to tests and adding setup commands to other tests. It
 
will be repetitive work, but each fix should be straightforward.
 
 
Once that runs to completion (notice, nothing here has broken or changed
 
the nose runs), testr run --parallel will work. We should at that point
 
test to see how it is with time.
 
 
If testr run --parallel is still too slow, then we can go in and wrap
 
the setup fixtures with testresources and use a ResourcedTestCase so
 
that we get resource affinity in the test runs.
 
  
 
=== UI Changes ===
 
=== UI Changes ===
  
Output will change.
+
output will change.
 +
Hopefully we will not see the  logging from the skip exception from at the setup classes.
  
 
=== Code Changes ===
 
=== Code Changes ===
  
 +
Remove complex skip decisions, test selection should be done by attributes based on the configuration file and skip exceptions.
  
 +
=== Additional Notes ===
  
=== Security and Internal Server Error Considerations ===
+
The test cases rarely needs to writes to the volumes.
 
+
Smaller ()
=== Additional Notes ===
+
10GB volume storage will not be enough, but the Thin provisioning  can help.
  
10G will not be enough, but the Thin provisioning  can help.
+
Probably we will need to use a more than 64 MB memory flavor type, it might be necessary for testing heat properly.
The test cases will rarely writes to the volumes.
 
More then 64 MB memory flavor type might be necessary for testing heat properly, but it will be rare case.
 
  
 
=== Migration ===
 
=== Migration ===
  
?
+
Change the tox settings.
 +
Add post processing
  
 
== Test/Demo Plan ==
 
== Test/Demo Plan ==
  
?
+
 
  
 
== Unresolved issues ==
 
== Unresolved issues ==
  
https://bugs.launchpad.net/nova/+bug/1016633
+
* https://bugs.launchpad.net/nova/+bug/1016633
 
+
* admin permissions are generally strong enough to observe and manipulate the system globally
 
+
* whitebox tests usually needs less noise
  
 
== BoF agenda and discussion ==
 
== BoF agenda and discussion ==

Latest revision as of 10:01, 13 June 2013

  • Launchpad Entry: TempestSpec:speed-up-tempest
  • Created: 18 May 2013
  • Contributors:

Summary

Use a horizontally and vertically scalable and extensible test runner.

Release Note

Rationale

The gate time has impact to the development speed. Parallel test case execution on multiple machines can dramatically speed up Unit Test execution.

User stories

  • 'Gate is tooo slow'
  • 'I would like use the same test runner with all OpenStack component and handling the test runs in similar way'
  • http://refstack.org/

Assumptions

  • Happier developers.
  • Faster user level API validation

Design

  • Replacing the notesttests test runner to testtools/testresources/testrepository combination.
  • Mitigate the common fixture usage
  • Maintain test capability without admin rights

Implementation

  1. Increase the single thread risks in order to be less confuse-able with parallel issues.

The tempest code uses waits for delete to mitigate the chance of running out from resources, this type of issue will happen in parallel.

  1. fix numbered, order dependent issues
  2. traceable logging ??
  3. add an option to old and new code path
  4. scale horizontally
  5. Add test case scheduler which supports resource reuse


UI Changes

output will change. Hopefully we will not see the logging from the skip exception from at the setup classes.

Code Changes

Remove complex skip decisions, test selection should be done by attributes based on the configuration file and skip exceptions.

Additional Notes

The test cases rarely needs to writes to the volumes. Smaller () 10GB volume storage will not be enough, but the Thin provisioning can help.

Probably we will need to use a more than 64 MB memory flavor type, it might be necessary for testing heat properly.

Migration

Change the tox settings. Add post processing

Test/Demo Plan

Unresolved issues

BoF agenda and discussion