Jump to: navigation, search

Difference between revisions of "NeutronThirdPartyTesting"

(Log & Test Results Filesystem Layout)
(Log & Test Results Filesystem Layout)
Line 36: Line 36:
 
Third-Party CI systems '''MUST''' provide [http://ci.openstack.org/third_party.html#requirements 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 '''MUST''' provide [http://ci.openstack.org/third_party.html#requirements 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
+
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:
 
At the root of the results - there should be the following:

Revision as of 21:56, 10 June 2014

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 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 (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. 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