Jump to: navigation, search


< Cinder
Revision as of 23:30, 10 May 2016 by Thingee (talk | contribs) (FAQ: adding trigger ci requirement)

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.

Third Party CI Requirements

  • See the official Third Party Testing wiki.
  • Test all volume drivers your company has integrated in Cinder.
  • Post all test results. Even if you have failure results, those need to be posted.
  • 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. If you've submitted your change to gerrit, you can use something like the following:

function pre_test_hook {
    echo "Cherry-picking latest driver from gerrit"
    cd $BASE/new/cinder

    # fetch latest patchset from gerrit

    # set this to your gerrit change number

                      sort -t/ -k 5 -n | tail -n1 | cut -d$'\t' -f2)

    if [ -z "$LATEST_PATCHSET" ]; then
        echo "Failed to determine latest patchset of $PATCHSET_BASE from $UPSTREAM_REMOTE"
        exit 1

    echo "Latest patchset ref is $LATEST_PATCHSET"

    git fetch $UPSTREAM_REMOTE $LATEST_PATCHSET && git cherry-pick FETCH_HEAD

If you haven't submitted your change to gerrit yet, you'll have to fetch the change from your own repository (github or otherwise). For example:

function pre_test_hook {
    echo "Cherry-picking latest driver from private repository"
    cd $BASE/new/cinder


    git fetch $VENDOR_REMOTE $REFSPEC && git cherry-pick FETCH_HEAD

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. This was agreed in a discussion on October 15th 2014. In a discussion on April 8th 2015, it was agreed that open source solutions that have Infra hosted CI's could have the chance to vote.

How do I test FC drivers?

Use PCI Passthrough to give the VM access to the FC PCI Device Scripts available here: http://git.openstack.org/cgit/openstack/third-party-ci-tools/tree/provisioning_scripts/fibre_channel

How do I trigger my CI to rerun on gerrit comments?

It is required for your CI to rerun jobs if the following comment is posted in a gerrit review:

"run-<CI NAME>"

So if your CI account name is "Super Cool Storage CI", the CI should be able to be retriggered by leaving the comment:

run-Super Cool Storage CI

CI's do not need to kick off tests until Jenkin's has given a +1, though it is up to the maintainer if you want to trigger immediately on all patchsets.

For the openstack-ci configuration, change the following to switch to only trigger on a Jenkin's +1:

In layout.yaml: Delete the line:

     - event: patchset-created

And then add:

     - event: comment-added
           - verified: 1
             username: Jenkins