[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [OSSTEST PATCH v11 16/20] ts-openstack-tempest: Update list of skipped tests



On Fri, Jun 23, 2017 at 04:38:05PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [OSSTEST PATCH v11 16/20] ts-openstack-tempest: 
> Update list of skipped tests"):
> > On Fri, Jun 23, 2017 at 02:47:37PM +0100, Ian Jackson wrote:
> > > Again, does this not mean we're going to suffer a maintenance burden
> > > as tempest grows new inapplicable tests ?
> > 
> > That exactly what is happening with the OpenStack CI loop, from time to
> > time, there are new tests, that can fail, and diffenrent ways to fix
> > this (fix the bug, fix a configuration, or just skip the tests).
> > 
> > Recently, we've actually push the list of tests to skip into nova.git,
> > but I think it is only available in master.
> 
> Aha.  Well, if the stable branch is stable then the set of tests to
> skip there is probably stable too ?  And on master it's built-in ?  So
> this actually won't be a problem - in the sense that this will be
> approximately the last necessary update to the list of tests to skip ?

The built-in list is to be consume by the CI, it is not used
automatically. It a bash script to be sourced. I have not yet try to
have osstest use it. That will be for later.

> > > Which makes me think: maybe the tempest tests want to be substeps
> > > anyway.  Is that possible ?  (Does tempest speak subunit or
> > > something ?)
> > 
> > I think it is subunit, yes. And I've got the command that is been run by
> > tempest (as it's printed on stdout).
> > 
> > running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
> > OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
> > OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \
> > OS_TEST_LOCK_PATH=${OS_TEST_LOCK_PATH:-${TMPDIR:-'/tmp'}} \
> > ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./} 
> > ${OS_TEST_PATH:-./tempest/test_discover} --list
> > 
> > then several:
> > running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
> > OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
> > OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \
> > OS_TEST_LOCK_PATH=${OS_TEST_LOCK_PATH:-${TMPDIR:-'/tmp'}} \
> > ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./} 
> > ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpzSNsrB
> 
> It would be really good to have those individual subunit results as
> substeps.  There is no subunit parser in osstest yet but we could have
> one.
> 
> What version of subunit does it print out ?  The subunit v1 protocol
> is lovely and simple but there is a Second System :-/.

Right now, tempest print on stdout something much simpler, lines liked
this:
{1} 
tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
 [71.009969s] ... ok
Followed by summary of all test, and the output of failed tests.

But it can be told to print subunit v2, which can be pipped to a different
program to transform into want we want, including simple cvs, subunit v1, and
other.

I thing we could try to parse subunit v1, grab the start and finish time
of a test, the result, and the output of the tests. And have all that as
subunit. During my manual tests, `tempest run --subunit ... | subunit-2to1`
only print the stuff about a tests once it is finish, so I guess we'll
have to rewrite substep_start() (or another function) to take time as
parameter.

> I guess that tempest doesn't stop on the first failed test ?  So
> perhaps we could just tolerate the failed-but-not-skipped tests ?

It does not, it run everything, no matter how many test fails.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.