[openstack-dev] [nova][qa] Testing with ephemeral/swap disks

Matt Riedemann mriedem at linux.vnet.ibm.com
Mon Nov 7 16:03:18 UTC 2016


Nova has a known gap in integration testing of ephemeral/swap disks, 
especially around resizes and migrations.

In Newton, Diana Clarke worked on a Tempest patch to verify the size of 
disks before and after a resize:

https://review.openstack.org/#/c/338411/

The QA team took issue with that patch because it creates specific 
flavors which might not work in all clouds, which is a valid concern.

At the summit some of the Nova people talked about what if we just added 
ephemeral/swap to the flavors that devstack creates and puts in 
tempest.conf - then we'd get some implicit coverage of those by default. 
That doesn't really help non-devstack CI systems, but I'm not entirely 
sure it matters, at least right now.

If we did have a specific test for this, like Diana's above, then we 
could just skip the test if the flavors in tempest.conf don't have 
ephemeral/swap defined. That would allow us to test this in the upstream 
CI, and external CI could also test it if they wanted to, but it 
wouldn't break external CI.

Would that be OK? Or are there other issues with that approach?

Alternatively we could work on some in-tree functional tests if those 
would work, but someone would have to investigate that. Note that the 
existing functional tests in Nova are not running libvirt, or glance, or 
any other external service - they only run a wsgi app server and a 
database (sqlite by default).

There has been talk of creating a nova-dsvm-integration job (there are 
differing opinions on if that should use devstack or not) which wouldn't 
run Tempest tests, just in-tree integration tests. So they could test 
things that aren't going through the REST API, like the image cache. The 
problem with this extra job is the lack of warm bodies to work on a POC.

So having brought these up - does anyone want to volunteer to explore 
these options or have issues with either one?

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list