interop/2016.01/procedure.rst
Mark T. Voelker 35d8985013 Add Guidance on Modifying Tests, Filing Flags
It's now come up a couple of times that we've found people modifying
tests in order to pass them.  Although seems obvious that not testing
things the same way across all clouds voids any guarantee of
interoperability, we should make this explit in the guidance we provide.
It's been proposed that one reason folks may be modifying tests is that
they don't clearly understand what they need to do in order to file a
flag request when they run into a problem, so they try to fix what they
think is wrong with the test instead.

This patch makes three changes to help address the issue:

1.) It adds a section to the 2016.01 guidance (which is currently
linked to from http://openstack.org/interop) to make it explicitly
clear that tests shouldn't be modified.

2.) Assuming that the interop website will be updated to point to the
most recent Guideline at some point, it creates the same guidance for
2016.08.

3.) It ammends HACKING to include simple instructions and an example
of how to file a flag request.  The individual guidelines' guidance
files also point to HACKING so folks know to look there.

Change-Id: I2f57a852da3181714e87d8e689dd5a1cb33cb417
2016-10-07 00:39:58 -04:00

4.7 KiB
Executable File

2016.01 DefCore Testing

Testing against DefCore 2016.01 Capabilities

https://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json

Tempest can be run standalone, or under a test runner such as refstack-client or rally. If only testing against DefCore capabilities, you can use the --load-list argument and a file containing a list of the DefCore tests. If run with the refstack-client, test output will be parsed to list only passing tests in a JSON formatted file. We recommend running under refstack-client.

The test names of the capabilities are derived from a recent release of Tempest, from the time of capability approval. Keep in mind that Tempest is under active development, and tests may move. If you're not seeing full coverage, please consider reverting back to a Tempest sha that more closely matches the capability release date. The git SHA of Tempest that was known to be working at the time the Guideline was approved is listed in the Guideline JSON document itself (just search for "git-sha"). Please contact Chris Hoge <interop@openstack.org> for assistance if needed.

It's important to run a recent version of Tempest, as major bugs related to network provisioning have been fixed. Some tests are still flagged due to outstanding bugs in the Tempest library, particularly tests that require SSH. We are working on correcting these bugs upstream. Please note that although some tests are flagged because of bugs, there is still an expectation that the capabilities covered by the tests are available.

In addition to testing required capabilities, we are also interested in collecting data on which API tests are being passed by production clouds. This information will be very useful in determining which capabilities will be used to define future releases. For that reason, we ask that you run all tests rather than just the required subset when submitting results to the OpenStack Foundation.

It is important to note that you MUST NOT modify the Tempest tests in any way. Modifying the tests means that Capability being tested is validated in a different way on your cloud than it is on other clouds, which voids any guarantee of interoperability. If you're having problems passing all required tests, please contact Chris Hoge <interop@openstack.org> for assistance or consider filing a request to have the tests flagged. Please refer to HACKING for information on valid reasons to flag a test and how to file a flag request. Results from modified tests cannot be accpeted as valid for trademark licensing purposes.

DefCore Recommended Test Procedure

The following procedure is recommended, but not required for testing DefCore. This procedure assumes you're running a Linux test platform (Ubuntu 14.04 or CentOS 7 have been verified) with administrator privileges.

  • Download the RefStack client:

    git clone https://git.openstack.org/openstack/refstack-client

  • In the refstack-client directory, install tempest and required dependencies. You may specify a specific tag of tempest with the -t option.

    ./setup_env

  • Optionally, download a list of test from the RefStack site. We strongly encourage you to run the full set of api tests, as this not only qualifies you for the trademark but also gives the DefCore team feedback on deployed capabilities to help us determine future guidelines. https://refstack.openstack.org/api/v1/guidelines/2016.01/tests?type=required

  • Configure tempest.conf for your cloud. If you need assistance in common parameters or settings contact interop@openstack.org. The recommended configuration is to use one non-admin account, defined in account.yaml with dynamic credentials disabled. More information is available in the configuration guide at http://docs.openstack.org/developer/tempest/configuration.html

  • You can run within the refstack, from the refstack-client directory either against all api tests or against the downloaded test list.

    ./refstack-client test -c ~/tempest.conf

    ./refstack-client test -c ~/tempest.conf --test-list <test-list-file-name>

  • Review the test results, and when you're satisfied, upload it to RefStack server then send them to interop@openstack.org.

    ./refstack-client upload <Path of results file>

  • The results are stored in a JSON file in the directory. You can also check your result on the RefStack server https://refstack.openstack.org:

    .tempest/.testrepository

  • Every effort should be made to pass all of the required tests, but you will want to compare any lists of failed tests to the list of flagged tests. The refstack server will automatically grade tests results, taking into account flagged tests.