top of page

OpenStack Integration Test Suite

1. Tempest

This is a set of integration tests to be run against a live OpenStack cluster. Tempest has batteries of tests for OpenStack API validation, Scenarios, and other specific tests useful in validating an OpenStack deployment.

2. Design Principles

Tempest Design Principles that we strive to live by.

  • Tempest should be able to run against any OpenStack cloud, be it a one node devstack install, a 20 node lxc cloud, or a 1000 node kvm cloud.

  • Tempest should be explicit in testing features. It is easy to auto discover features of a cloud incorrectly, and give people an incorrect assessment of their cloud. Explicit is always better.

  • Tempest uses OpenStack public interfaces. Tests in Tempest should only touch public interfaces, API calls (native or 3rd party), or libraries.

  • Tempest should not touch private or implementation specific interfaces. This means not directly going to the database, not directly hitting the hypervisors, not testing extensions not included in the OpenStack base. If there is some feature of OpenStack that is not verifiable through standard interfaces, this should be considered a possible enhancement.

  • Tempest strives for complete coverage of the OpenStack API and common scenarios that demonstrate a working cloud.

  • Tempest drives load in an OpenStack cloud. By including a broad array of API and scenario tests Tempest can be reused in whole or in parts as load generation for an OpenStack cloud.

  • Tempest should attempt to clean up after itself, whenever possible we should tear down resources when done.

  • Tempest should be self-testing.

3. Installing Tempest on Centos 7

3.1 Pre-requisite package installation

You should be having the OpenStack setup (live OpenStack cluster)

Run the following commands:

  • yum update

  • yum makecache fast

  • yum install git

  • yum install python-pip

  • pip install –upgrade pip ( - - the command has 2 hyphen)

  • pip install tox

  • yum install libffi libffi-devel

  • yum groupinstall ‘Development Tools’

  • yum install openssl-devel

  • pip install requests[security]

  • pip install –upgrade pyopenssl

  • pip install –upgrade ndg-httpsclient

  • pip install –upgrade pyasn1

3.2 Getting Started with Tempest

Follow the below commands to get the tempest folder:

Clone latest Tempest code into the directory you want to:

  • git clone

To start you need to create a configuration file. The easiest way to create a configuration file is to generate a sample in the etc/ directory


· oslo-config-generator --config-file \

tools/config/config-generator.tempest.conf \

--output-file etc/tempest.conf

After that, open up the etc/tempest.conf file and edit the configuration variables to match valid data in your environment. This includes your Keystone endpoint, a valid user and credentials, and reference data to be used in testing.

Below is the link to Sample tempest.conf file. (Make sure the generated conf file matches with that of sample in the link below)

3.3 Editing the tempest configuration file

Make sure you get the entire tempest.conf file as shown in the link. If you get incomplete file, make sure you delete and re-run the config-file generator command.

  • vi etc/tempest.conf

In [identity] section:

In order for tempest to be able to talk to your OpenStack deployment you need to provide it with information about how it communicates with keystone. This involves configuring the following options in the identity section:

  1. auth_version

  2. uri

  3. uri_v3

The auth_versionoption is used to tell tempest whether it should be using keystone’s v2 or v3 api for communicating with keystone. (except for the identity api tests which will test a specific version) The 2 uri options are used to tell tempest the url of the keystone endpoint. The urioption is used for keystone v2 request and uri_v3is used for keystone v3. You want to ensure that which ever version you set forauth_versionhas its uri option defined.

If, for example, your host IP is, change this line in tempest.conf

uri =

to make it

uri =

In our case it’s the host name “controller”

uri = http://controller:5000/v2.0/

uri_v3 = http://controller:5000/v3.0/

auth_version = v2

username = admin

password = 123CDS

tenant_name = admin

admin_username = admin

admin_password = 123CDS

admin_tenant_name = admin

alt_username = prasant

alt_password = 123CDS

alt_tenant_name = prasant

3.4 Installing required dependencies of Tempest

In tempest directory, you will be having requirements.txt file. This file contains all required dependencies. Inorder to install all these dependencies run the following command:

  • pip install –r requirements.txt

3.5 Unit Tests

3.5.1 Using tox

Tempest also has a set of unit tests which test the Tempest code itself.

Tempest is not tied to any single test runner, but testr is the most commonly used tool. Also, the nosetests test runner is notrecommended to run Tempest.

testr is a test runner and is part of testrepository.

Using testr:

To use testr you can use the existing wrappers, tox and

There will be a tox.ini file in the root directory of every project.

Within the tox.ini file you might see any of the following envlist options:


envlist = py26,py27,py33,pep8,pylint

In order to run tox against one of these environments, you run, for example:

tox -e py27

Tox Run-time:

Why does tox take so long to run? The reason tox takes a long time is two-fold: On the first run it has to create a virtual environment, which can take anywhere from 5 to 30+ minutes depending on the project and the system. The other reason is that it just takes a long time to run all of the test cases in some of the projects.

3.5.2 Using testr directly instead of tox

  • testr init

This creates test repository folder which is hidden. ( /tempest/.testrepository/ )

testr can be quite useful when run directly as well. First source your test venv.

· source .tox/py27/bin/activate

With the venv sourced we can run testr directly.

· testr help

· testr run --parallel

After tests have run you can view the failing tests then run only that list of tests.

· testr failing

· testr run --failing

3.5.3 To run one test

To run one test follow the commands below:

  • source .tox/py27/bin/activate

  • <test>

Volume based tests are present in =>


3.5.4 Test Logs

You will find that testr keeps test logs in .testrepository/$TEST_RUN_NUMBER. These logs are subunit streams and are used to determine which tests are failing when you run testr failing.

bottom of page