Jump to: navigation, search

Difference between revisions of "DriverLog"

(Tracked drivers)
(How To’s)
Line 115: Line 115:
 
             "name": "Neutron Plugin",
 
             "name": "Neutron Plugin",
 
             "wiki": "http://extrcdn.extremenetworks.com/wp-content/uploads/2014/02/SDN_OpenStack_Install_Guide_Final1.pdf",
 
             "wiki": "http://extrcdn.extremenetworks.com/wp-content/uploads/2014/02/SDN_OpenStack_Install_Guide_Final1.pdf",
             "os_versions": [
+
             "releases": ["Icehouse"]
            ]
 
 
         }
 
         }
* Records in config file should be sorted by key - (project_id, vendor, name). The configuration file automatically validated against the config file scheme.  
+
* Records in config file should be sorted by key - (project_id, vendor). The configuration file automatically validated against the config file scheme.  
 
* A project DriverLog Core Engineer receives a request to review a commit.  
 
* A project DriverLog Core Engineer receives a request to review a commit.  
 
* An DriverLog Core Engineer makes a review. If everything is ok  an DriverLog Core Engineer merges an update.
 
* An DriverLog Core Engineer makes a review. If everything is ok  an DriverLog Core Engineer merges an update.
* A driver is getting displayed in the Drivers list on the DriverLog Dashboard. ‘CI tested’ column will be empty.
+
* A driver is getting displayed in the Drivers list on the DriverLog Dashboard. ‘CI tested’ column will show cross mark meaning that CI is not present. 'In trunk' column will show a list of releases specified in field 'releases'.
  
 
==== External CI verification ====
 
==== External CI verification ====
* In order to update to this level, a vendor must have deployed and external voting CI environment that runs automatic tests against a driver on every commit. Instructions for setting up external CI can be found here:
+
* Vendor can deploy an external voting CI environment that runs automatic tests against a driver on every commit. Instructions for setting up external CI can be found here:
 
:* [http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ Understanding the OpenStack CI System]
 
:* [http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ Understanding the OpenStack CI System]
 
:* [http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/comment-page-1/#comment-216389 Setting Up an External OpenStack Testing System – Part 1]
 
:* [http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/comment-page-1/#comment-216389 Setting Up an External OpenStack Testing System – Part 1]
 
:* [http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/ Setting Up an External OpenStack Testing System – Part 2]
 
:* [http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/ Setting Up an External OpenStack Testing System – Part 2]
* Once a vendor set up an external CI environment and tested a driver there he/she can change the driver’s verification level to ‘external_ci_verification’.
+
 
* A verification level ‘external_ci_verification’  and a CI environment ID (ci_id) should be set up in the configuration file.
+
In order to config DriverLog to poll external CI for current verification status field 'ci_id' needs to be provided. 'ci_id' is Gerrit Id of external CI, see example below:
''Note: ci_id is a required field, otherwise backend will not find voting marks in Gerrit.''
 
 
     {
 
     {
 
             "project_id": "openstack/neutron",
 
             "project_id": "openstack/neutron",
Line 140: Line 138:
 
             },
 
             },
 
             "wiki": "https://wiki.openstack.org/wiki/Neutron/EmbraneNeutronPlugin",
 
             "wiki": "https://wiki.openstack.org/wiki/Neutron/EmbraneNeutronPlugin",
             "os_versions": [
+
             "ci_id": "eci"
                {
 
                    "verification": "external_ci_verification",
 
                    "ci_id": "eci"
 
                }
 
            ]
 
 
         },
 
         },
  
Line 156: Line 149:
 
:* If pair ci_id+branch appears for the first time, then the backend stores the pair with test run result and link  
 
:* If pair ci_id+branch appears for the first time, then the backend stores the pair with test run result and link  
 
''Note: Only known ci_id’s from default_data.json are processed by the backend.''
 
''Note: Only known ci_id’s from default_data.json are processed by the backend.''
 +
 
== Release Notes ==
 
== Release Notes ==
 
'''Release 0.1'''
 
'''Release 0.1'''

Revision as of 15:42, 25 April 2014

Mission

The DriverLog project is on a mission to provide information about drivers and plugins developed for both OpenStack itself and projects related to OpenStack. When it comes to a production OpenStack deployment a customer wants to have an assurance that certain hardware/virtual appliances will really work with certain OpenStack components. The DriverLog project aimed at enabling potential users/developers to quickly determine if a particular vendor driver exists and has been tested for a particular OpenStack release.

Target audience

Vendors

  • Readily available, community supported driver marketplace.
  • One common and measurable version of the truth with regards to vendor driver compatibility with OpenStack releases.

OpenStack customers

  • Standardized information OpenStack users can use and trust.
  • Improved quality and reliability of OpenStack.

OpenStack Community

  • Encourage more participation of vendors in the community.
  • Meet the quality, reliability and openness expected by OpenStack users.
  • Accelerate OpenStack mission of building a universal, open fabric for an heterogeneous set of components while avoiding component fragmentation and non-operable point products.

Description

DriverLog is a service that collects and processes information about OpenStack drivers, their maintainers, availability in trunk, CI testing status and makes it possible to visualize it in a convenient web dashboard. The Driver dashboard makes it possible to view data by project, vendor and other factors.

Tracked projects

DriverLog stores a list of projects and their drivers in the configuration file default_data.json. Any contributor can add an untracked project. The projects section represents the list of tracked projects. It has the following format:

"projects": [
       {
           "id": "openstack/cinder",
           "name": "Cinder (Block Storage)"
       },
       {
           "id": "openstack/neutron",
           "name": "Neutron (Networking)"
       },
       {
           "id": "openstack/nova",
           "name": "Nova (Compute)"
       },
       {
           "id": "openstack/sahara",
           "name": "Sahara (Data Processing)"
       }
   ],

Tracked releases

The releases section represents the list of OpenStack releases. It has the following format:

   "releases": [
       {
           "id": "austin",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Austin"
       },
       {
           "id": "bexar",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Bexar"
       },
       {
           "id": "cactus",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Cactus"
       },
       {
           "id": "diablo",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Diablo"
       },
       {
           "id": "essex",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Essex"
       },
       {
           "id": "folsom",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Folsom"
       },
       {
           "id": "grizzly",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly"
       },
       {
           "id": "havana",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Havana"
       },
       {
           "id": "icehouse",
           "wiki": "https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse"
       },
       {
           "id": "juno",
           "wiki": "https://wiki.openstack.org/wiki/Releases"
       }
   ],

Tracked drivers

Any contributor can add an untracked driver. The drivers section represents the list of tracked drivers . It has the following format:

        {
           "project_id": "openstack/cinder",
           "vendor": "EMC",
           "name": "SMI-S (FC)",
           "maintainer": {
               "name": "Xing Yang",
               "email": "xing.yang@emc.com"
           },
           "releases": ["Icehouse"]
       },

For each driver the following parameters were specified:

  • project_id - OpenStack project
  • vendor - Driver vendor
  • name - Driver name
  • Description- - driver description
  • Maintainer - information about driver maintainer, including name, email, irc id
  • wiki - link to the OpenStack wiki page with driver setup instructions
  • releases - a list of OpenStack releases the driver supported in

How To’s

Add a new driver to DriverLog

  • A vendor wants to add a new driver.
  • A vendor adds a new driver section to the DriverLog JSON file.
        {
            "project_id": "openstack/neutron",
            "vendor": "Extreme Networks",
            "name": "Neutron Plugin",
            "wiki": "http://extrcdn.extremenetworks.com/wp-content/uploads/2014/02/SDN_OpenStack_Install_Guide_Final1.pdf",
            "releases": ["Icehouse"]
        }
  • Records in config file should be sorted by key - (project_id, vendor). The configuration file automatically validated against the config file scheme.
  • A project DriverLog Core Engineer receives a request to review a commit.
  • An DriverLog Core Engineer makes a review. If everything is ok an DriverLog Core Engineer merges an update.
  • A driver is getting displayed in the Drivers list on the DriverLog Dashboard. ‘CI tested’ column will show cross mark meaning that CI is not present. 'In trunk' column will show a list of releases specified in field 'releases'.

External CI verification

  • Vendor can deploy an external voting CI environment that runs automatic tests against a driver on every commit. Instructions for setting up external CI can be found here:

In order to config DriverLog to poll external CI for current verification status field 'ci_id' needs to be provided. 'ci_id' is Gerrit Id of external CI, see example below:

    {
           "project_id": "openstack/neutron",
           "vendor": "Embrane",
           "name": "Neutron Plugin",
           "maintainer": {
               "name": "Ivar Lazzaro",
               "irc": "ivar-lazzaro"
           },
           "wiki": "https://wiki.openstack.org/wiki/Neutron/EmbraneNeutronPlugin",
           "ci_id": "eci"
       },
  • A vendor submits a patch.
  • A DriverLog Core Engineer makes a review. If everything is ok he/she merges an update.
  • The actual results of driver testing are stored in Gerrit. The backend runs as a scheduled background butch performing the following logic every 4 hours:
  • The DriverLog backend by using CI environment ID (ci_id) recognizes which Gerrit reviews are related to this driver.
  • The backend parses all merged patches from new to old.
  • For every review it checks ci_id and branch (version).
  • If pair ci_id+branch appears for the first time, then the backend stores the pair with test run result and link

Note: Only known ci_id’s from default_data.json are processed by the backend.

Release Notes

Release 0.1

  • Nova, Cinder, Neutron and Sahara projects included into DriverLog.
  • Information about supported drivers from projects’ wiki pages was manually converted into JSON config file:

Code

Source

https://github.com/stackforge/driverlog

Pending Code Reviews

https://review.openstack.org/#/q/status:open+driverlog,n,z

Project space

https://launchpad.net/driverlog

Blueprints

https://blueprints.launchpad.net/driverlog

Bugs

https://bugs.launchpad.net/driverlog

Web-site

http://staging.stackalytics.com/driverlog/