Rename isolated creds to dynamic creds
Renaming the isolated_creds module to dynamic_creds module, and rename
the IsolatedCreds class to DynamicCredentialProvider in preparation
to migration to tempest-lib.
Partially implements bp tempest-library
Change-Id: I78a4884e980ef7d0103639cb3792a54c69fb7761
diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst
index dd2f56b..f228040 100644
--- a/doc/source/configuration.rst
+++ b/doc/source/configuration.rst
@@ -63,39 +63,41 @@
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tempest currently also has 3 different internal methods for providing
-authentication to tests. Tenant isolation, locking test accounts, and
+authentication to tests. Dynamic credentials, locking test accounts, and
non-locking test accounts. Depending on which one is in use the configuration
of tempest is slightly different.
-Tenant Isolation
-""""""""""""""""
-Tenant isolation was originally create to enable running tempest in parallel.
+Dynamic Credentials
+"""""""""""""""""""
+Dynamic Credentials (formerly known as Tenant isolation) was originally created
+to enable running tempest in parallel.
For each test class it creates a unique set of user credentials to use for the
tests in the class. It can create up to 3 sets of username, password, and
tenant/project names for a primary user, an admin user, and an alternate user.
-To enable and use tenant isolation you only need to configure 2 things:
+To enable and use dynamic credentials you only need to configure 2 things:
#. A set of admin credentials with permissions to create users and
tenants/projects. This is specified in the auth section with the
- admin_username, admin_tenant_name, admin_domain_name, and admin_password
+ admin_username, admin_tenant_name, admin_domain_name and admin_password
options
- #. To enable tenant_isolation in the auth section with the
- allow_tenant_isolation option.
+ #. To enable dynamic_creds in the auth section with the
+ use_dynamic_credentials option.
This is also the currently the default credential provider enabled by tempest,
due to it's common use and ease of configuration.
It is worth pointing out that depending on your cloud configuration you might
-need to assign a role to each of the users created Tempest's tenant isolation.
+need to assign a role to each of the users created by Tempest's dynamic
+credentials.
This can be set using the *tempest_roles* option. It takes in a list of role
-names each of which will be assigned to each of the users created by tenant
-isolation. This option will not have any effect when set and tempest is not
-configured to use tenant isolation.
+names each of which will be assigned to each of the users created by dynamic
+credentials. This option will not have any effect when set and tempest is not
+configured to use dynamic credentials.
Locking Test Accounts (aka accounts.yaml or accounts file)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-For a long time using tenant isolation was the only method available if you
+For a long time using dynamic credentials was the only method available if you
wanted to enable parallel execution of tempest tests. However this was
insufficient for certain use cases because of the admin credentials requirement
to create the credential sets on demand. To get around that the accounts.yaml
@@ -103,7 +105,7 @@
using the list of credentials instead of creating them on demand. With locking
test accounts each test class will reserve a set of credentials from the
accounts.yaml before executing any of its tests so that each class is isolated
-like in tenant isolation.
+like with dynamic credentials.
To enable and use locking test accounts you need do a few things:
@@ -117,7 +119,7 @@
#. Provide tempest with the location of your accounts.yaml file with the
test_accounts_file option in the auth section
- #. Set allow_tenant_isolation = False in the auth group
+ #. Set use_dynamic_credentials = False in the auth group
It is worth pointing out that each set of credentials in the accounts.yaml
should have a unique tenant. This is required to provide proper isolation
@@ -149,7 +151,7 @@
And in the auth section:
- #. allow_tenant_isolation = False
+ #. use_dynamic_credentials = False
#. comment out 'test_accounts_file' or keep it as empty
It only makes sense to use it if parallel execution isn't needed, since tempest
@@ -295,28 +297,28 @@
misconfiguration or a missing network in the accounts file.
-With Tenant Isolation
-"""""""""""""""""""""
-With tenant isolation enabled and using nova-network then nothing changes. Your
-only option for configuration is to either set a fixed network name or not.
+With Dynamic Credentials
+""""""""""""""""""""""""
+With dynamic credentials enabled and using nova-network then nothing changes.
+Your only option for configuration is to either set a fixed network name or not.
However, in most cases it shouldn't matter because nova-network should have no
problem booting a server with multiple networks. If this is not the case for
your cloud then using an accounts file is recommended because it provides the
-necessary flexibility to describe your configuration. Tenant isolation is not
+necessary flexibility to describe your configuration. Dynamic credentials is not
able to dynamically allocate things as necessary if neutron is not enabled.
-With neutron and tenant isolation enabled there should not be any additional
+With neutron and dynamic credentials enabled there should not be any additional
configuration necessary to enable Tempest to create servers with working
networking, assuming you have properly configured the network section to work
for your cloud. Tempest will dynamically create the neutron resources necessary
to enable using servers with that network. Also, just as with the accounts
-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
+file, if you specify a fixed network name while using neutron and dynamic
+credentials 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.
-However, there is an option *create_isolated_networks* to disable tenant
-isolation's automatic provisioning of network resources. If this option is
+However, there is an option *create_isolated_networks* to disable dynamic
+credentials's automatic provisioning of network resources. If this option is
used you will have to either rely on there only being a single/default network
available for the server creation, or use *fixed_network_name* to inform
Tempest which network to use.