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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev