Open Stack

On Tue, Jul 16, 2013 at 10:17:00AM -0400, David Kranz wrote:
> On 07/16/2013 10:06 AM, Matthew Treinish wrote:
> >Snip...
> >Let's enhance the stress tests with a new actions and we could define a
> >good mixture of them for automatic testing.
> >
> >What do you mean with "more sane"? Could you propose a better interface?
> >I just think the whole definition with a JSON file is a little strange. I
> >would also like to see an easier way to run the different actions easily
> >serially or in parallel (if it makes sense). If you look at the stress tox job
> >I had to call run_stress multiple times, once for each JSON action that existed.
> >I think it would be better if you could pass a list of actions you want to run
> >and have run_stress handle run them serially. (or something like that).
> >
> >It also might make sense to add an optional flag to run_tests.sh so the stress
> >suite is runnable from both tox and run_tests.
> >
> The point of the json file was that the main driver needs to accept
> a list of tests to fire off. Each test may itself accept arguments
> specific to that test and these arguments also need to be provided.
> You could use something other than json but I think you need some
> kind of hierarchical structure other than straight command line
> arguments.  Maybe it was not clear that the json file can be a list
> of tests, even though the original example just had one. If you give
> a list of tests now they will run in parallel, a desired use case,
> but we could easily add another top-level flag that says whether to
> run in parallel or sequentially.
> 

That is actually all that I was looking for, I probably should have asked
before I wrote the tox job... 

I've fixed things up here:
https://review.openstack.org/37262
https://review.openstack.org/37263

Using JSON works fine, I'm just not used to it. I think what really is needed
is a little documentation on how this is supposed to work. I'll write something
up in a bit and push it out.

-Matt Treinish