Bug 1311555 - Trove-api fails to start when deployed using packstack on RHEL 7.2
Trove-api fails to start when deployed using packstack on RHEL 7.2
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack (Show other bugs)
8.0 (Liberty)
All Linux
high Severity high
: ---
: 8.0 (Liberty)
Assigned To: Ivan Chavero
Luigi Toscano
: AutomationBlocker, Triaged, ZStream
Depends On: 1350855
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-24 08:01 EST by Luigi Toscano
Modified: 2016-06-29 09:58 EDT (History)
10 users (show)

See Also:
Fixed In Version: openstack-packstack-7.0.0-0.17.dev1702.g490e674.el7ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1282928
: 1350855 (view as bug list)
Environment:
Last Closed: 2016-06-29 09:58:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 266977 None None None 2016-02-24 08:01 EST
OpenStack gerrit 280258 None None None 2016-03-03 03:33 EST

  None (edit)
Description Luigi Toscano 2016-02-24 08:01:06 EST
+++ This bug was initially created as a clone of Bug #1282928 +++

Description of problem:
When using Packstack to deploy an RHEL-OSP environment on RHEL 7.2 RC1.1, Trove-api fails due to the configuration api_paste_config = api-paste.ini. This value is incorrect and should be updated to api_paste_config = /usr/share/trove/trove-dist-paste.ini

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


How reproducible:
It is easily reproducible, just need to use Packstack to deploy an RHEL-OSP environment.


Steps to Reproduce:
1. Deploy RHEL-OSP using packstack on RHEL 7.2 RC1.1. Trove-api should fail during installation.

Actual results:
Trove-api fails to start.

Expected results:
Trove-api should start.


Additional info:

2015-11-13 17:43:34.172 1102 CRITICAL root [-] ValueError: Cannot resolve relative uri 'config:None'; no relative_to keyword argument given
2015-11-13 17:43:34.172 1102 ERROR root Traceback (most recent call last):
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/bin/trove-api", line 10, in <module>
2015-11-13 17:43:34.172 1102 ERROR root     sys.exit(main())
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/trove/cmd/common.py", line 73, in run
2015-11-13 17:43:34.172 1102 ERROR root     return main_function(conf)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/trove/cmd/api.py", line 27, in main
2015-11-13 17:43:34.172 1102 ERROR root     host=CONF.bind_host, workers=workers)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/trove/common/wsgi.py", line 79, in launch
2015-11-13 17:43:34.172 1102 ERROR root     app = pastedeploy.paste_deploy_app(paste_config_file, app_name, data)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/trove/common/pastedeploy.py", line 161, in paste_deploy_app
2015-11-13 17:43:34.172 1102 ERROR root     return deploy.loadapp("config:%s" % paste_config_file, name=app_name)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247, in loadapp
2015-11-13 17:43:34.172 1102 ERROR root return loadobj(APP, uri, name=name, **kw)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 271, in loadobj
2015-11-13 17:43:34.172 1102 ERROR root     global_conf=global_conf)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 296, in loadcontext
2015-11-13 17:43:34.172 1102 ERROR root     global_conf=global_conf)
2015-11-13 17:43:34.172 1102 ERROR root   File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 308, in _loadconfig
2015-11-13 17:43:34.172 1102 ERROR root     "argument given" % uri)
2015-11-13 17:43:34.172 1102 ERROR root ValueError: Cannot resolve relative uri 'config:None'; no relative_to keyword argument given
2015-11-13 17:43:34.172 1102 ERROR root


--- Additional comment from Telles Nobrega on 2015-11-18 09:07:11 EST ---

The bug can be found using Packstack Liberty 7.0.0.dev1661.gaf13b7e and openstack-puppet-modules-7.0.1-1.el7ost.noarch. Also the Trove packages in version 4.0.0-2.el7ost.noarch.


--- Additional comment from Ivan Chavero on 2015-12-08 01:35:15 EST ---

Could not reproduce on RHEL 7.1, checking with RHEL 7.2

--- Additional comment from Luigi Toscano on 2015-12-08 03:26:36 EST ---

(In reply to Ivan Chavero from comment #5)
> Could not reproduce on RHEL 7.1, checking with RHEL 7.2

On which version of packstack? (the change of product for the bug can be make things a bit more complicated)

--- Additional comment from Ivan Chavero on 2015-12-09 05:42:51 EST ---

(In reply to Luigi Toscano from comment #6)
> (In reply to Ivan Chavero from comment #5)
> > Could not reproduce on RHEL 7.1, checking with RHEL 7.2
> 
> On which version of packstack? (the change of product for the bug can be
> make things a bit more complicated)

packstack master branch from source

--- Additional comment from Luigi Toscano on 2016-01-13 09:44:49 EST ---

Any updates?

--- Additional comment from Martin Magr on 2016-01-13 10:24:14 EST ---

The default value of api_paste_config is really api-paste.ini. Checked also RDO openstack-trove rpm and the default value is not modified on packaging level. This value sadly is not possible to modify via Puppet modules, hence I've created the clone to openstack-puppet-modules and submitted workaround in Packstack. 

Though I don't think '/usr/share/trove/trove-dist-paste.ini' is a correct value, because in RDO package the api-paste.ini file is located in /etc/trove

[1] https://github.com/openstack/trove/blob/master/etc/trove/trove.conf.sample#L154
Comment 1 Luigi Toscano 2016-02-24 08:05:18 EST
I don't know what happened, but even if the bug is fixed in RDO (master and liberty) it looks like something is out of sync in the corresponding packages in RHOP. Installation of packstack still lead to the same result: incorrect paste file.

The value written by packstack in /etc/trove/trove.conf is
api_paste_config = /etc/trove/api-paste.ini

The one which works is:
api_paste_config = /usr/share/trove/trove-dist-paste.ini

So please, either
- make sure that the latter is used or
- sync the packaging so that the it works as for RDO.

Reproduced with:
openstack-packstack-7.0.0-0.12.dev1699.g8f54936.el7ost.noarch
openstack-packstack-puppet-7.0.0-0.12.dev1699.g8f54936.el7ost.noarch
openstack-puppet-modules-7.0.6-2.el7ost.noarch
puppet-3.6.2-2.el7.noarch

python-trove-4.0.0-3.el7ost.noarch
openstack-trove-api-4.0.0-3.el7ost.noarch
openstack-trove-conductor-4.0.0-3.el7ost.noarch
openstack-trove-common-4.0.0-3.el7ost.noarch
openstack-trove-4.0.0-3.el7ost.noarch
openstack-trove-taskmanager-4.0.0-3.el7ost.noarch
Comment 2 Martin Magr 2016-04-20 09:55:17 EDT
This patch is already merged and backported to stable/liberty upstream, so in case it was not built in 8.0 rebase in past, it should be backported to OSP-8.
Comment 3 Ivan Chavero 2016-06-02 00:31:16 EDT
This was already fixed, i added the most recent package so it can be checked by QE
Comment 5 Luigi Toscano 2016-06-17 10:55:42 EDT
Same results as reported in #1 : the value written by packstack in /etc/trove/trove.conf is
api_paste_config = /etc/trove/api-paste.ini
but the file is installed under /usr/share/trove/trove-dist-paste.ini.
Trove services starts when api_paste_config is changed to point the latter.

Reproduced on:
openstack-packstack-7.0.0-0.19.dev1702.g490e674.el7ost.noarch
openstack-packstack-puppet-7.0.0-0.19.dev1702.g490e674.el7ost.noarch
openstack-puppet-modules-7.1.1-1.el7ost.noarch
puppet-3.6.2-2.el7.noarch

openstack-trove-4.0.0-4.el7ost.noarch
openstack-trove-api-4.0.0-4.el7ost.noarch
openstack-trove-common-4.0.0-4.el7ost.noarch
openstack-trove-conductor-4.0.0-4.el7ost.noarch
openstack-trove-taskmanager-4.0.0-4.el7ost.noarch
python-trove-4.0.0-4.el7ost.noarch
python-troveclient-1.3.0-1.el7ost.noarch
Comment 6 Ivan Chavero 2016-06-20 12:00:32 EDT
This seems to be like a packaging problem, the openstack-trove RPM changes the name of the paste file to trove-dist-paste.ini

From the openstack-trove spec file for liberty:
install -p -D -m 644 etc/%{project}/api-paste.ini %{buildroot}%{_datadir}/%{project}/%{project}-dist-paste.ini

This problem has been solved in the mitaka openstack-trove package.

I think this should be addressed in other bug. What do you think?
Comment 7 Luigi Toscano 2016-06-20 12:09:52 EDT
The behavior is exactly the same as explained in the description of the bug. Some changes have been made and now, instead of
api_paste_config = api-paste.ini
there is 
api_paste_config = /etc/trove/api-paste.ini

but it's still the incorrect value. Yes, it could be a packaging problem, but it's still a bug of openstack-packstack, so I disagree with creating another bug, also because how would this bug be handled? It's not closed.
Comment 8 Ivan Chavero 2016-06-23 20:41:02 EDT
(In reply to Luigi Toscano from comment #7)
> The behavior is exactly the same as explained in the description of the bug.
> Some changes have been made and now, instead of
> api_paste_config = api-paste.ini
> there is 
> api_paste_config = /etc/trove/api-paste.ini
> 
> but it's still the incorrect value. Yes, it could be a packaging problem,
> but it's still a bug of openstack-packstack, so I disagree with creating
> another bug, also because how would this bug be handled? It's not closed.

I don't agree this is a packstack bug, the Trove package is changing the correct name to trove-dist-paste.ini, trying to set this file apart from the configuration by adding the word "dist" to the filename. 

Also is evident that is a packaging bug because this behaviour has been changed on the current mitaka Trove package, so packstack is not the proper place to fix this.

As for the way this bug should be handled it should be dependent on the Trove packaging bug.
Comment 9 Luigi Toscano 2016-06-24 04:57:51 EDT
You convinced me. So, do you prefer a new bug (because there was in fact  something changed in packstack and this bug should track it) or reassign this bug to openstack-trove?
Comment 11 errata-xmlrpc 2016-06-29 09:58:10 EDT
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/RHBA-2016:1354

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