Jump to: navigation, search


Revision as of 23:25, 25 July 2014 by Dougwig (talk | contribs) (examples for running subset of tests)

This page documents the requirements, expectations, and ideally the results of all third party testing done by open source and vendor plugins for the Neutron project.

What Is Expected of Third Party CI System for Neutron

Neutron expects Third Party CI systems to follow the requirements set by the Infrastructure team as well as the Neutron Third Party CI guidelines below. Please ping the PTL in #openstack-neutron or send an email to the openstack-dev ML (with subject [neutron]) with any questions. Be aware that the Infrastructure documentation as well as this wikipage are living documents and undergo changes. Track changes to the infrastructure documentation using this url (and please review the patches) and check this page on a regular basis for updates.

What Changes to Run Against

Ideally, your 3rd Party CI system will run against all changes pushed against Neutron. You may even want to run against certain Nova changes which affect the interfaces between Nova and Neutron. Realistically, this may be too many changes for your CI system to handle. A recommendation in this case is as follows:

  • Run against all changes made to your own driver/plugin.
  • Run against basic changes to the Neutron DB code.
  • Run against all changes to the sub-system your driver belongs to:
    • For ML2, all ML2 changes.
    • For LBaaS, all LBaaS changes.
    • For VPNaaS, all VPNaaS changes.
    • For FWaaS, all FWaaS changes.

What Tests To Run

The short answer here is: More is always better. The more tests you run, the better covered you are. A possibly more realistic answer is as follows:

  • Network API tests (git link).
  • Network scenario tests (The test_network_* tests here).
  • Any tests written specifically for your setup.


  • Run with the test filter: 'network'. This will include all neutron specific tests as well as any other tests that are tagged as requiring networking. An example tempest setup for devstack-gate:
   export DEVSTACK_GATE_TEMPEST_REGEX='(?!.*\[.*\bslow\b.*\])((network)|(neutron))'

... an example setup for LBaaS:

   export DEVSTACK_GATE_TEMPEST_REGEX='(?!.*\[.*\bslow\b.*\])(alancer|SimpleReadOnlyNeutron|tempest.api.network)'

Third Party CI Voting

By default, the infra team will not allow voting by new 3rd party CI systems. The way to get your 3rd party CI system to vote is to talk with the Neutron PTL, who will let infra know the system is ready to vote. The requirements for a new system to be given voting rights are as follows:

  • A new system must be up and running for a month, with a track record of voting on the sandbox system.
  • A new system must correctly run and pass tests on patches for the third party driver/plugin for a month.
  • A new system must have a logfile setup and retention setup similar to the below.

Once the system has been running for a month, the owner of the third party CI system can contact the Neutron PTL to have a conversation about getting voting rights upstream.

The general process to get these voting rights is outlined here. Please follow that, taking note of the guidelines Neutron also places on voting for it's CI systems.

A third party system can have it's voting rights removed as well. If the system becomes unstable (stops running, voting, or start providing inaccurate results), the Neutron PTL will make an attempt to contact the owner and copy the openstack-dev mailing list. If no response is received within 2 days, the Neutron PTL will remove voting rights for the third party CI system. If a response is received, the owner will work to correct the issue. If the issue cannot be addressed in a reasonable amount of time, the voting rights will be temporarily removed.

Keep in mind that a running third party CI setup is required for upstream plugins and drivers. If the system is not functioning, the code for which it is designed to protect becomes at risk of being removed from upstream.

Log & Test Results Filesystem Layout

Third-Party CI systems MUST provide logs and configuration data to help developers troubleshoot test failures. A third-party CI that DOES NOT post logs should be a candidate for removal, and new CI systems MUST post logs before they can be awarded voting privileges.

Third party CI systems should follow the filesystem layout convention of the OpenStack CI system. Please store your logs as viewable in a web browser, in a directory structure. Requiring the user to download a giant tarball is not acceptable.

At the root of the results - there should be the following:

  • console.html.gz - contains the output of stdout of the test run
  • local.conf / localrc - contains the setup used for this run
  • logs/

Logs must be a directory, which contains the following:

  • Log files for each screen session that DevStack creates and launches an OpenStack component in
  • Test result files
    • testr_results.html.gz
    • tempest.txt.gz