Open Stack

On 08/05/2013 04:07 PM, David Kranz wrote:
> On 08/05/2013 07:40 AM, Koderer, Marc wrote:
>> I see two use cases for stress tests:
>>
>>    - As a developer I want to find bugs that occur under load (like
>> raise conditions)
>>      --> Leads to many small and concurrent api tests
>>    - As OPS/QA I want to generate load that simulates real life load in a
>>      production-like system
>>      --> Leads to concurrent scenario test
>
> IMO the most important use case for stress tests is the first. The idea
> is to make something happen, like a race condition, that would only
> happen rarely, and be much harder to debug, under real life load.
> Simulating real life load is important for performance tuning and the
> like but I think is a bit different. I don't see why the stress
> framework should not be able to support concurrent scenario tests though.

hi David and thanks for contributing to this.

I agree on the idea that a stress test could address both the need of a 
dev to stress a particular functionality as also the need of an op to 
stress with concurrency a particular scenario, so I think this[1] is 
welcomed and stress tests don't necessarily have to share a particular 
structure.

At the same time, because of that some practical issues come into the 
discussion. There is a submission[2] which basically is an attempt to 
add some suspend/resume stop/start pause/unpause stress tests.

We either suggest to merge those into a single class and turn it into 
some sort of stress scenario or keep them in different files but in that 
case I wonder, how would that be different from just running the 
existing api tests, for those same functionalities, concurrently via[1] ?

1. https://review.openstack.org/#/c/38980/
2. https://review.openstack.org/#/c/39752/
-- 
Giulio Fidente
GPG KEY: 08D733BA | IRC: giulivo