Bug 1432919 - Tempest does not properly initialize the configuration values from tempest.conf for some plugins
Summary: Tempest does not properly initialize the configuration values from tempest.co...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tempest
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
Target Milestone: beta
: 11.0 (Ocata)
Assignee: Chandan Kumar
QA Contact: Luigi Toscano
Depends On:
Blocks: 1434849
TreeView+ depends on / blocked
Reported: 2017-03-16 12:18 UTC by Luigi Toscano
Modified: 2017-05-17 20:08 UTC (History)
7 users (show)

Fixed In Version: openstack-tempest-15.0.0-2.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1434849 (view as bug list)
Last Closed: 2017-05-17 20:08:28 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 385460 0 None None None 2017-03-30 11:16:24 UTC
OpenStack gerrit 443630 0 None None None 2017-03-30 11:17:26 UTC
RDO 5892 0 None None None 2017-03-30 11:14:46 UTC
RDO 5913 0 None None None 2017-03-30 11:13:31 UTC
RDO 5915 0 None None None 2017-03-30 10:59:47 UTC
Red Hat Product Errata RHEA-2017:1245 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 23:01:50 UTC

Description Luigi Toscano 2017-03-16 12:18:40 UTC
Description of problem:

When tempest initialize the configuration of the plugins, it performs some magic with the global CONF object. Until some recent fixes (post-15.0), the magic was wrong and the values from tempest.conf related to some Tempest plugins using ServiceClients in some conditions (i.e. referring CONF in the plugin initialization) where not set.

This is visible in the Sahara Tempest plugin, which references the CONF object in the plugin initialization. This lead to an wrong nested call in the initialization phase for that object, and the final result is that the values in the data-processing section of tempest.conf are ignored.

Result: if for example endpoint list does not match (as it happens for v3) the default value (publicURL), the endpoint_type option for Sahara is ignored, tempest picks a random endpoint which ends up being the wrong one and the connection does not work.
The Sahara plugin is specifically affected because it was one of the few that migrated to the new manager interface (based on ServiceClients) AND its configuration section in tempest.conf has a dash, which lead to some specific code to handle it in the Sahara plugin (wrongly) which triggered the issue.

The fix for this (i.e. properly initialize the CONF object for tempest plugins) was fixed in Tempest in the following commits:


There are some other cleanup in the Sahara plugin but the commit above seems to  be enough. They should either backported to the package, or the package could be bumped to a git snapshot (I think a new tag of Tempest will be created when Mitaka is EOL).

Version-Release number of selected component (if applicable):

Comment 2 Luigi Toscano 2017-05-03 15:25:40 UTC
The failure previously observed  when the Sahara Tempest plugin was used have not been seen anymore in a long series of runs (i.e. the value of the endpoint is picked correctly and the test can be executed). This is consistent with the expected behavior after backporting the patches mentioned above.

Verified on:

Comment 3 errata-xmlrpc 2017-05-17 20:08:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.