Fixing man page generation

The man page generation failed with sphinx v1.1.3
and docutils 0.10 and 0.11.

Adding docutils==0.9.1 to the test-requirements.txt
in order to solve this issue.

The docutils==0.9.1 is on the common OpenStack dependency list.

Several doc creation warning and error also fixed by this change.

Change-Id: Icb412876f5a989e6b8aa4886f2a246127a76521a
This commit is contained in:
Attila Fazekas
2013-07-24 10:25:02 +02:00
parent 47ff791416
commit 58d23301ba
6 changed files with 17 additions and 16 deletions

View File

@@ -1,5 +1,3 @@
::
Tempest - The OpenStack Integration Test Suite
==============================================
@@ -37,9 +35,11 @@ and reference data to be used in testing.
Tempest is not tied to any single test runner, but Nose been the most commonly
used tool. After setting up your configuration file, you can execute
the set of Tempest tests by using ``nosetests`` ::
$> nosetests tempest
To run one single test ::
$> nosetests -sv tempest.api.compute.servers.test_server_actions.py:
ServerActionsTestJSON.test_rebuild_nonexistent_server

View File

@@ -1,6 +1,6 @@
============
============================
Tempest Field Guide Overview
============
============================
Tempest is designed to be useful for a large number of different
environments. This includes being useful for gating commits to
@@ -26,7 +26,7 @@ documented in a README.rst file in the directory.
api
------------
---
API tests are validation tests for the OpenStack API. They should not
use the existing python clients for OpenStack, but should instead use
@@ -41,7 +41,7 @@ frameworks.
cli
------------
---
CLI tests use the openstack CLI to interact with the OpenStack
cloud. CLI testing in unit tests is somewhat difficult because unlike
@@ -51,7 +51,7 @@ prereqs having a running OpenStack cloud.
scenario
------------
--------
Scenario tests are complex "through path" tests for OpenStack
functionality. They are typically a series of steps where complicated
@@ -61,7 +61,7 @@ Scenario tests can and should use the OpenStack python clients.
stress
-----------
------
Stress tests are designed to stress an OpenStack environment by
running a high workload against it and seeing what breaks. Tools may
@@ -72,7 +72,7 @@ moves into here.
thirdparty
------------
----------
Many openstack components include 3rdparty API support. It is
completely legitimate for Tempest to include tests of 3rdparty APIs,
@@ -81,7 +81,7 @@ validation.
whitebox
----------
--------
Whitebox tests are tests which require access to the database of the
target OpenStack machine to verify internal state after operations

View File

@@ -12,7 +12,7 @@ operations on a cloud that are hard to test via unit tests.
Why are these tests in tempest?
-------------------------------
These tests exist here because it is extremely difficult to build a
functional enough environment in the python-*client unit tests to
functional enough environment in the python-\*client unit tests to
provide this kind of testing. Because we already put up a cloud in the
gate with devstack + tempest it was decided it was better to have
these as a side tree in tempest instead of another QA effort which

View File

@@ -1,9 +1,9 @@
Tempest Guide to Third Party API tests
========
======================================
What are these tests?
--------
---------------------
Third party tests are tests for non native OpenStack APIs that are
part of OpenStack projects. If we ship an API, we're really required
@@ -14,14 +14,14 @@ which should be tested as part of normal process.
Why are these tests in tempest?
--------
-------------------------------
If we ship an API in an OpenStack component, there should be tests in
tempest to exercise it in some way.
Scope of these tests
--------
--------------------
Third party API testing should be limited to the functional testing of
third party API compliance. Complex scenarios should be avoided, and

View File

@@ -4,4 +4,5 @@ pyflakes==0.7.2
flake8==2.0
hacking>=0.5.6,<0.7
# needed for doc build
docutils==0.9.1
sphinx>=1.1.2