Jump to: navigation, search

NeutronThirdPartyTesting

Revision as of 20:15, 10 June 2014 by Mestery (talk | contribs)

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 guidelines below. Please ping the PTL in #openstack-neutron or send an email to the openstack-dev ML (with subject [neutron]) with any questions.

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 (github link).
  • Network scenario tests (The test_network_* tests here).
  • Any tests written specifically for your setup.

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.

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

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

  • console.html.gz - contains the output of stdout of the test 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