Open Stack

Any assistance would be good.

Right now we really just need 'gate' attr added to basically all the non 
skipped methods, we can prune later. Once 'gate' looks to be ~ full, we 
can flip over check and gate to use that.

I think long term the approach we're going to need to go with is 3 sets 
of tests:

smoke (< 10 mins)
gate (< 45 mins)
full (everything)

All projects gate on gate

Periodic runs of full - daily, more often?

Tempest check runs full (but not gate), it's advisory.

Some on demand facility for people to run full.

At this point I'm not adding my +2 to any more tests (only approving 
fixes to existing tests) until we get gate tag in, as I don't think we 
should be running any longer than we currently are.

     -Sean

On 05/11/2013 10:01 AM, Giulio Fidente wrote:
> On 05/10/2013 12:37 PM, Sean Dague wrote:
>> In the past month we've added 5 - 7 minutes to the tempest run length.
>
> I feel partly involved into the slowdown so I'd like to get some
> guidance over the issue.
>
> Take as an example the following, it is going to create two volume
> snapshots (one per test):
>
> https://review.openstack.org/#/c/28176/
>
> The tests share an origin volume created by setUpClass but repeat the
> snap creation step.
>
> Creating the snap is the purpose of one of the tests indeed, while the
> second is attempting to create a snap-based volume, essentially
> repeating the initial snapshot creation as one of the steps.
>
> One could speed up things by moving also the snapshot creation in the
> setUpClass but, from my pov, creating a snapshot successfully is what we
> want to test, not just a setup step.
>
> So, what shoul be the right approach in such a situation?
>
> Also, in relation to the gating issue, should a _slow_ test like this be
> part of the gating or shouldn't it? It's slow but can we run the gating
> without checking if one is still able to create a volume snapshot?
>
>> Any volunteers for this? The patches are straight forward, but they will
>> take a little time.
>
> How about splitting this per component? I'd volunteer for the volume
> tests. Adding the import should be an easy task, picking up the right
> tests for taking would be a separate commit as I expect a number of new
> suggestions in the review comments. Makes sense?


-- 
Sean Dague
http://dague.net