diff options
author | Matthew Treinish <mtreinish@kortar.org> | 2015-04-15 16:25:48 -0400 |
---|---|---|
committer | Matthew Treinish <mtreinish@kortar.org> | 2015-04-21 10:35:50 -0400 |
commit | 3220cadc51d9fea86e3ffda6e73e640b997c1684 (patch) | |
tree | 889d006efbd8961c4b7a8f07483ed1a0cc33040b | |
parent | 7909e12f398864179937227494bee6eed642cf56 (diff) | |
download | tempest-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.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. |