History

Anna Babich f5a25fe997 Functional tests for trigger-crash-dump (microversion 2.17)

It's a resource-consuming task to implement full-flow (up to getting
and reading a dump file) functional test for trigger-crash-dump.
We need to upload Ubuntu image for booting an instance based on it,
and to install kdump with its further configuring on this instance.

Here, the "light" version of functional test is proposed.
It's based on knowledge that trigger-crash-dump uses a NMI injection,
and when the 'trigger-crash-dump' operation is executed,
instance's kernel receives the MNI signal, and an appropriate
message will appear in the instance's log.

Wait_for_server_os_boot() method has been added to ClientTestBase
to check if instance's operating system  is completely booted.

The _create_server() method has been removed since the change
which puts this method to the base test class has been merged.

Change-Id: I2313c5d37a7cf87a8d75e37c93aab136cf028ec1

2016-02-22 18:58:21 +02:00

api

Add functional tests launcher for py3 env

2016-01-15 13:25:33 +00:00

hooks

Add functional tests launcher for py3 env

2016-01-15 13:25:33 +00:00

Functional tests for trigger-crash-dump (microversion 2.17)

2016-02-22 18:58:21 +02:00

__init__.py

First pass at tempest_lib based functional testing

2015-01-28 15:44:43 -08:00

base.py

Functional tests for trigger-crash-dump (microversion 2.17)

2016-02-22 18:58:21 +02:00

clouds.yaml.sample

Add a sample clouds.yaml

2015-06-15 17:53:21 +00:00

README.rst

[docs] Fix length of underline

2015-09-17 16:07:11 +03:00

README.rst

python-novaclient functional testing

Idea

Over time we have noticed two issues with novaclient unit tests.

Does not exercise the CLI
We can get the expected server behavior wrong, and test the wrong thing.

We are using functional tests, run against a running cloud (primarily devstack), to address these two cases.

Additionally these functional tests can be considered example uses of python-novaclient.

These tests started out in tempest as read only nova CLI tests, to make sure the CLI didn't simply stacktrace when being used (which happened on multiple occasions).

Testing Theory

We are treating python-novaclient as legacy code, so we do not want to spend a lot of effort adding in missing features. In the future the CLI will move to python-openstackclient, and the python API will be based on the OpenStack SDK project. But until that happens we still need better functional testing, to prevent regressions etc.

Since python-novaclient has two uses, CLI and python API, we should have two sets of functional tests. CLI and python API. The python API tests should never use the CLI. But the CLI tests can use the python API where adding native support to the CLI for the required functionality would involve a non trivial amount of work.

Functional Test Guidelines

Consume credentials via standard client environmental variables:
```
OS_USERNAME
OS_PASSWORD
OS_TENANT_NAME
OS_AUTH_URL
```
Try not to require an additional configuration file