Cloud, Drivers and OpenStack DriverLog, Part 2: Getting Started

In this first stage, Mirantis is coordinating the DriverLog project, working with PTLs and driver maintainers. We are all trying to make participation as frictionless as possible for vendors and other interested community members. See part one for more background on DriverLog.

Some minimal constraints are needed, at this stage, to limit workloads. Since the largest number of third-party drivers are developed for Nova, Cinder, Neutron and Sahara, the first phase of DriverLog will focus on drivers for these components.

To populate the DriverLog database, information about specific drivers was gathered from project wiki pages:

• https://wiki.openstack.org/wiki/HypervisorSupportMatrix

• https://wiki.openstack.org/wiki/CinderSupportMatrix

• https://wiki.openstack.org/wiki/Neutron#Using_Neutron

Vendors involved have been extremely supportive in validating the correctness of source information.

Initially, most drivers will be listed without the CI tested mark, to be promoted to CI tested status in due course. To get promoted to CI tested vendors have to a) an external CI test harness, as described in instructions below; b) update DriverLog records

• Understanding the OpenStack CI System

• Setting Up an External OpenStack Testing System – Part 1

• Setting Up an External OpenStack Testing System – Part 2

• Adding CI Tested Mark to your DriverLog Record

To simplify things, below is the really quick summary of the content from the 4 documents above.

How to add a driver and get a CI tested mark?

The DriverLog process makes it fairly simple for vendors to enter new drivers and update driver listings. The CI tested mark is then gained through successful automated test-suite execution in tandem with a vendor’s external continuous integration setup.

Including Drivers

A vendor can include its driver like this:

1. The vendor adds a new section to the JSON “database,” committing a patch. For example:

       {

           "project_id": "openstack/cinder",

           "vendor": "Ceph",

           "name": "Ceph RADOS Block Device (RBD)",

           "description": "The Ceph RADOS Block Device driver  allows to use Ceph RADOS block devices (RBD) for volumes.",

           "maintainer": {

               "name": "Josh Durgin, Mike Perez, Edward Hope-Morley",

               "email": "josh.durgin@inktank.com"

           },

           "wiki": "http://docs.openstack.org/trunk/config-reference/content/ceph-rados.html",

           "releases": ["Cactus", "Diablo", "Essex", "Folsom", "Grizzly", "Havana", "Icehouse"]

       },

2. The configuration file is automatically validated against the config file scheme.

3. An DriverLog Core Engineer receives a request to review a commit.

4. The engineer reviews and, if all is well, merges the update.

5. The DriverLog dashboard displays the new information.

CI tested Status

Vendors can set up a Jenkins CI server and test their drivers with Tempest in synch with target branches. Once Tempest has run, the vendor can update information about their driver in the DriverLog database and promote it to ‘CI tested,’ like this:

1. The vendor patches the DriverLog configuration file, changing the verification level on their driver to ‘external_ci_verification’ and including a ci_id:

2. An DriverLog Core Engineer reviews, approves, and merges the update.

3. The actual results of driver testing are stored in Gerrit. The DriverLog back-end uses ci_id to determine which Gerrit reviews are related to this driver.

4. The DriverLog Dashboard displays the driver’s new status and provides a drill-down:

5. By clicking on [Verification Status] users can see an OpenStack Code Review page. The Review page contains the comment from CI with links to log files.