Bug 1432919

Summary: Tempest does not properly initialize the configuration values from tempest.conf for some plugins
Product: Red Hat OpenStack Reporter: Luigi Toscano <ltoscano>
Component: openstack-tempestAssignee: Chandan Kumar <chkumar>
Status: CLOSED ERRATA QA Contact: Luigi Toscano <ltoscano>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 11.0 (Ocata)CC: apevec, jschluet, lhh, mcornea, mkopec, slinaber, yprokule
Target Milestone: beta   
Target Release: 11.0 (Ocata)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tempest-15.0.0-2.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1434849 (view as bug list) Environment:
Last Closed: 2017-05-17 20:08:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1434849    

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:

http://git.openstack.org/cgit/openstack/tempest/commit/?id=8b23c79325ed68c6741683690c69ba3f64acfc2e
http://git.openstack.org/cgit/openstack/tempest/commit/?id=382a6f12a38baab47918fb902ccfd9e451c04800



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):
openstack-tempest-15.0.0-1.el7ost.noarch
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:
openstack-tempest-1:15.0.0-2.el7ost.noarch
openstack-sahara-tests-0.4.1-1.el7ost.noarch
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.

https://access.redhat.com/errata/RHEA-2017:1245