diff options
author | Jenkins <jenkins@review.openstack.org> | 2015-04-23 21:06:58 +0000 |
---|---|---|
committer | Gerrit Code Review <review@openstack.org> | 2015-04-23 21:06:59 +0000 |
commit | 8b167e48f2a01c5abd8acfbd869ca3ee9badd807 (patch) | |
tree | eb63905b7227084916d55b5bb256c36211c834ff | |
parent | dec44bda44e1f9a6168560dc2699267967e9bae2 (diff) | |
parent | 3220cadc51d9fea86e3ffda6e73e640b997c1684 (diff) | |
download | tempest-8b167e48f2a01c5abd8acfbd869ca3ee9badd807.tar.gz |
Merge "Add config guide section on service feature enabled sections"
-rw-r--r-- | doc/source/configuration.rst | 35 |
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. |