Jump to: navigation, search

Difference between revisions of "Cinder/tested-3rdParty-drivers"

(As discussed in the cinder midcycle meetup, we will only expose the OpenStack Infra preferred solution.)
Line 21: Line 21:
** [https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample Sample Jenkins Job Builder Job Template for Cinder drivers]
** [https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample Sample Jenkins Job Builder Job Template for Cinder drivers]
** Fork of Jay Pipe's external test repo and more up-to-date. Uses nodepool.
** Fork of Jay Pipe's external test repo and more up-to-date. Uses nodepool.
* Simple OpenStack Continuous Integration (sos-ci)
** [https://github.com/j-griffith/sos-ci Git repo]
** Builds Devstack virtual machines with Ansible.
* Jay Pipe's external testing series
* Jay Pipe's external testing series

Revision as of 21:50, 15 April 2015

Driver Testing


The Cinder community (and other OpenStack projects) have agreed that if a vendor wishes to submit a driver for their particular storage device that said vendor should also be required to set up a third party CI system in their lab which runs Tempest volume tests against their storage device for every Cinder commit, and provides feedback in to Gerrit.


All volume drivers need to have a CI by end of K-3, March 19th 2015. Failure will result in removal in the Kilo release. Discussion regarding this was in the #openstack-meeting IRC room during the Cinder meeting. Read discussion logs

Third Party CI Requirements

  • See the official Third Party Testing wiki.
  • Test all volume drivers your company has integrated in Cinder.
  • Test all fabrics your solution uses.

For example, if your company has two volume drivers in Cinder and they both use ISCSI and FibreChannel, you would need to have a CI that tests against four backends and reports the results for each backend, for every Cinder upstream patch

Existing CI Solutions

Current Reporting Cinder CI's

See the list.


  • Join Third Party Meeting
  • Reach out to IRC nicks DuncanT or asselin on Freenode #openstack-cinder.


What tests do I use?

Use the OpenStack integration test suite Tempest. The volume related tests can be started with the following command from a Tempest repo:

tox -e all -- volume | tee -a console.log.out

For those using devstack-gate export this variable before running the job:


How do I configure DevStack so my Driver Passes Tempest?

Sample local.conf for devstack setup.


# These options define  expected driver capabilities

# These options allow you to specify a branch other than "master" be used

# Disable security groups entirely


How do I run my CI to test all cinder patches with my driver not yet merged?

If using devstack-gate use the pre-test-hook to cherry-pick your driver on top of the cinder patch under review

function pre_test_hook {
        cd $BASE/new/cinder
        git fetch https://review.openstack.org/openstack/cinder $PATCH && git cherry-pick FETCH_HEAD

Note you may wish to substitute the review.openstack.org repo with your own github location before submitting to gerrit.

Otherwise you can make the changes prior to calling stack.sh or via a custom devstack plugin.

When thirdparty CI voting will be required?

Once third party CI's become more common and stable, we'll revisit the subject. For now you can review the discussion on the decision.