History

Dan Smith ef8e054b6b Make import wait check for store status During a glance import, if we fail, we are not going to change the state of the image in all cases, and definitely not to 'active'. Thus waiting for active just means we keep polling a broken image for a long time, wasting resources. We should also be checking the list of failed stores, and if something pops in there, abort right then and there. This patch makes us use the wait_for_image_imported_to_stores() waiter, and modifies it to not look at image['stores'] if no stores are provided. In the case where we don't have multistore support enabled, we won't be able to know that the import failed until we time out, but otherwise we will (barring a glance bug for which I also have a fix). This also makes the waiter not fail on KeyError if os_glance_failed_import is not present on the image, as would be the case if used when stores are not enabled. Note that I'm doing this because sometimes web-download fails in the gate due to a timeout trying to pull our http_image and we just keep looping until our own timeout instead of noticing. It also means we just report "never reached active state" instead of what we know to be true, which is that import failed. Change-Id: Ie0569b84dd1c397a79d13af609bf23db52a2dfc8		2021-02-08 09:56:57 -08:00
..
compute	Merge "compute: Skip AttachVolumeShelveTestJSON when cross_az_attach unavailable"	2020-12-08 16:59:33 +00:00
identity	Add client methods and tests for system grants	2021-01-11 19:12:14 +00:00
image	Make import wait check for store status	2021-02-08 09:56:57 -08:00
network	[Trivial]Remove unused variables and methods	2020-11-19 01:19:12 +00:00
object_storage	Skip test_create_object_with_transfer_encoding	2020-11-25 04:16:45 +00:00
volume	Merge "Fix negative tests of update_volume for volume microversion 3.59"	2020-10-01 13:13:56 +00:00
README.rst	Doc: fix markups, capitalization and add 2 REVIEWING advices	2017-07-11 20:26:32 +02:00
__init__.py	Remove copyright from empty files	2014-01-14 03:02:04 +04:00

README.rst

Tempest Field Guide to API tests

What are these tests?

One of Tempest's prime function is to ensure that your OpenStack cloud works with the OpenStack API as documented. The current largest portion of Tempest code is devoted to test cases that do exactly this.

It's also important to test not only the expected positive path on APIs, but also to provide them with invalid data to ensure they fail in expected and documented ways. The latter type of tests is called negative tests in Tempest source code. Over the course of the OpenStack project Tempest has discovered many fundamental bugs by doing just this.

In order for some APIs to return meaningful results, there must be enough data in the system. This means these tests might start by spinning up a server, image, etc, then operating on it.

Why are these tests in Tempest?

This is one of the core missions for the Tempest project, and where it started. Many people use this bit of function in Tempest to ensure their clouds haven't broken the OpenStack API.

It could be argued that some of the negative testing could be done back in the projects themselves, and we might evolve there over time, but currently in the OpenStack gate this is a fundamentally important place to keep things.

Scope of these tests

API tests should always use the Tempest implementation of the OpenStack API, as we want to ensure that bugs aren't hidden by the official clients.

They should test specific API calls, and can build up complex state if it's needed for the API call to be meaningful.

They should send not only good data, but bad data at the API and look for error codes.

They should all be able to be run on their own, not depending on the state created by a previous test.