Testing for current Icehouse release
The idea of requiring drivers to run functional tests and certify is new to the Icehouse release. To get started with this process we've implemented a simple wrapper around the tempest volume.api tests. The process currently is for each vendor to run this certification test against their backend driver in their own environment. The wrapper is very simple, it just does a fresh clone of the cinder and tempest repos and restarts services, then runs the tempest volume.api tagged tests in the tempest suites and collects the output to a temporary log file.
This is far from extensive or ideal, however it's already uncovered a number of issues with existing drivers and has proven to be a beneficial process. Currently this is a manual process that we'd like to see run/updated at each milestone and at each RC for Icehouse. The current list of the most recent run of the certification tests and a link to the resultant log files is included in the table found at the bottom of this wiki page.
Testing requirements for upcoming Juno release
To be designated as compatible, a third-party plugin and/or driver code must implement external third party testing. The testing should be Tempest executed against a Devstack build with the proposed code changes. The environment managed by the vendor should be configured to incorporate the plugin and/or driver solution. The OpenStack Infrastructure team has provided details on how to integrate 3rd party testing at:
and Tempest can be found at:
The Cinder team expects that the third party testing will provide a +/-1 verify vote for all changes to a plugin or driver’s code. In addition, the Cinder team expects that the third party test will also vote on all code submissions by the jenkins user. The jenkins user regularly submits requirements changes and the Cinder team hopes to catch any possible regressions as early as possible.