### Overview This file explains how to do the `tempest.conf` configuration. The configuration itself has a lot of comment and direction on it and pretty self explanatory. This is just to clear possible confusions. ### Tenant Isolation * This is the dynamic credential creation method that allows running Tempest tests in parallel * It creates separate tenants, networks and users for different classes of tests. * It can create 3 types of users admin user, primary user, and alternative user. * It's the most commonly use and easy of configuration * To configure this option * [auth] - `use_dynamic_credentials = true` * [auth] - `create_isolated_networks = true` * [auth] - `admin_username`, `admin_tenant_name`, and `admin_password` to an admin credential that has permission to create users and tenants/projects. ### [auth] This section in `tempest.conf` file is very well commented. Insert corresponding domain name, user credentials, and yaml account file from your cloud. ### [compute] `img_ref =` the uuid of an available image on the cloud, tests will create servers using this image. (recommend cirros) `img_ref_alt =` uuid of an available image on the cloud, an alternative image tempest uses to create servers for tests. (This can be the same image in `img_ref`) `flavor_ref =` flavor id for server created from `img_ref`. This will be numbers (i.e. 1 or 2) it represents the flavor id `flavor_ref_alt =` flavor id for server created from `img_ref_alt`. (This has to be different than `flavor_ref`) `build_timeout = ` this is default 300 seconds, but sometime needs to be set to longer depends on the performance of the cloud's storage backend. `region = ` the region of the cloud environment is in ### [compute-feature-enabled] Follow the default options unless your cloud environment is supporting/not supporting that feature. For example if resize is enabled for the cloud set `resize = true` `api_extension = all` `change_password = false` ### [dashboard] `dashboard_url = ` The url of your cloud dashboard after login (e.g. https://my.cloud.com/) `login_url = ` The url of the login page on dashboard (e.g. https://my.cloud.com/auth/login/) ### [identity] `uri = https://my.cloud.com:5000/v2.0` `auth_version = v2` `region = ` corresponding region ### [identity-feature-enable] Again this depends on the cloud environment. If Keystone v3 is enabled set `api_v3 = true` `api_v2 = true` `api_v3 = false` `api_extensions = all` ### [image] `build_timeout = ` this might need to be set to longer when you have issues with image is in active state but test failed with timeout error ### [image-feature-enable] `api_v2 = true` `api_v1 = true` ### [negative] Use the default `test_generator = tempest.common.generator.negative_generator.NegativeTestGenerator` generates negative tests ### [network] `tenant_network_reachable = false` Because we choose `ssh_connect_method = floating` `public_network_id = ` this should be the uuid of the publicly reachable network, usually "public" on "admin" project `floating_network_name = ` **IMPORTANT** This is a lie. We see "Floating ip pool not found" error even with this specified. The floating network name (or floating network pool name) does NOT get passed to the tempest code. We have a hack around this which is to modify the `/root/tempest/.venv/lib/python2.7/site-packages/tempest_lib/common/rest_client.py` file. we modified the content of `body` in this following function ``` def request(self, method, url, extra_headers=False, headers=None, body=None): ... ... ... import json if url == "os-floating-ips" and body == json.dumps({}): body = json.dumps({'pool': 'public'}) resp, resp_body = self._request(method, url, headers=headers, body=body) ``` `public_router_id = ` do not need to be specified, leave blank. Unless Neutron has `allow_overlapping_ips = false` in it's configuration ### [network-feature-enable] `ipv6 = false` `api_extensions = security-group, l3_agent_scheduler, ext-gw-mode, binding, quotas, agent, dhcp_agent_scheduler, provider, router, extraroute, external-net, allowed-address-pairs, extra_dhcp_opt, router, service-type, dvr` these are the api extensions that's provided in staging area, it should be identical to production cluster. ### [scenario] This is the weird part. We never have great success with the scenario tests. Ideally scenario tests performs different use cases of OpenStack cloud using the API calls. It includes sshing into the instance which is also weird (will be explained in [validation] section). But to run scenario tests, you need to prepare a image directories (locally) that contains different formats of image files that will be used in the tests. The images can be found and downloaded from online. ``` img_dir = /root/cirros-img img_file = cirros-0.3.2-x86_64-disk.img ami_img_file = cirros-0.3.2-x86_64-blank.img ari_img_file = cirros-0.3.2-x86_64-initrd aki_img_file = cirros-0.3.2-x86_64-vmlinuz ``` ### [service_available] Set according to what services are available in the cloud. ### [stress] This requires access to the controller because it will look at the log files. I never did it. ### [validation] I disabled it because it has tons of issues, I asked on IRC, and read about it on the bug reports. This option just doesn't work as it should. But this is also last Summer (June 2015). And they did have a lot of updates since then so it might work now? `run_validation = ` boolean value to enable ssh on created servers and creation of additional validation resources to enable remote access. (Due to to the inconsistency of Tempest in handling ssh tests, disable this option for now) `connect_method = floating` `auth_method = keypair` `ip_version_for_ssh = 4` `image_ssh_user = cirros` if using cirros image `image_ssh_password = cubswin:)` if using cirros image ### [volume] `storage_protocol = ceph` for our backend. ceph has to be "ceph" it can NOT be "Ceph" of "CEPH" `vendor_name = Open Source` same as above, the vendor_name has to be "Open Source". ### [volume-feature-enabled] `multi_backend = false` `backup = false` `snapshot = true` `api_extensions = all` `api_v1 = true` `api_v2 = true`