summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatthew Treinish <mtreinish@kortar.org>2015-04-15 16:25:48 -0400
committerMatthew Treinish <mtreinish@kortar.org>2015-04-21 10:35:50 -0400
commit3220cadc51d9fea86e3ffda6e73e640b997c1684 (patch)
tree889d006efbd8961c4b7a8f07483ed1a0cc33040b
parent7909e12f398864179937227494bee6eed642cf56 (diff)
downloadtempest-3220cadc51d9fea86e3ffda6e73e640b997c1684.tar.gz
Add config guide section on service feature enabled sections
This commit adds another section to the tempest config guide outlining how the service feature enabled sections should be configured. Change-Id: Iaedf744068b3f91f72144efcaab5d9eaeb9adb0c
-rw-r--r--doc/source/configuration.rst35
1 files changed, 35 insertions, 0 deletions
diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst
index 661aa018d..ac72473fb 100644
--- a/doc/source/configuration.rst
+++ b/doc/source/configuration.rst
@@ -295,3 +295,38 @@ file, if you specify a fixed network name while using neutron and tenant
isolation it will enable running tests which require a static network and it
will additionally be used as a fallback for server creation. However, unlike
accounts.yaml this should never be triggered.
+
+Service feature configuration
+-----------------------------
+
+OpenStack provides its deployers a myriad of different configuration options
+to enable anyone deploying it to create a cloud tailor-made for any individual
+use case. It provides options for several different backend type, databases,
+message queues, etc. However, the downside to this configurability is that
+certain operations and features aren't supported depending on the configuration.
+These features may or may not be discoverable from the API so the burden is
+often on the user to figure out what the cloud they're talking to supports.
+Besides the obvious interoperability issues with this it also leaves Tempest
+in an interesting situation trying to figure out which tests are expected to
+work. However, Tempest tests do not rely on dynamic api discovery for a feature
+(assuming one exists). Instead Tempest has to be explicitly configured as to
+which optional features are enabled. This is in order to prevent bugs in the
+discovery mechanisms from masking failures.
+
+The service feature-enabled config sections are how Tempest addresses the
+optional feature question. Each service that has tests for optional features
+contains one of these sections. The only options in it are boolean options
+with the name of a feature which is used. If it is set to false any test which
+depends on that functionality will be skipped. For a complete list of all these
+options refer to the sample config file.
+
+
+API Extensions
+^^^^^^^^^^^^^^
+The service feature-enabled sections often contain an *api-extensions* option
+(or in the case of swift a *discoverable_apis* option) this is used to tell
+tempest which api extensions (or configurable middleware) is used in your
+deployment. It has 2 valid config states, either it contains a single value
+"all" (which is the default) which means that every api extension is assumed
+to be enabled, or it is set to a list of each individual extension that is
+enabled for that service.