Open Stack

On Tue, Feb 16, 2016 at 10:07:19AM +0100, Jordan Pittier wrote:
> Hi list,
> I understood we need to limit the number of tests and jobs that are run for
> each Tempest patch because our resources are not unlimited.
> 
> In Tempest, we have 5 multinode experimental jobs:
> 
> experimental-tempest-dsvm-multinode-full-dibtest
> gate-tempest-dsvm-multinode-full
> gate-tempest-dsvm-multinode-live-migration
> gate-tempest-dsvm-neutron-multinode-full
> gate-tempest-dsvm-neutron-dvr-multinode-full
> 
> These jobs largely overlap with the non-multinode jobs. What about tagging
> (with a python decorator) each test that really requires multiple nodes and
> only run those tests as part of the multinode jobs ?

So I don't think this is wise. I'm fine with adding a tag (or more
realistically a new decorator that sets the attr and bakes in the skip checks)
to mark tests that require more than 1 node to work. But, limiting all the
multinode jobs to just that set doesn't make too much sense to me. For most of
those jobs you listed the point is to verify that everything things work the
same at >1 node, not just features that require more than 1 node. (with likely
the exception of the live-migration job which I assume just runs live migration
tests)

What is probably a better question to ask is why we need 5 different multi-node
jobs in the tempest experimental queue? Tempest will always have a higher than
average number of tempest-dsvm jobs running because so much of the code is self
verifying. But, do all of those jobs really improve our coverage of tempest
code? Like what does the dibtest job buy us? Or why do we need 2 different
types of neutron deployments running?

-Matt Treinish


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160216/1e1b03c6/attachment.pgp>