Bug 1350855 - Trove-api fails to start when deployed using packstack on RHEL 7.2
Summary: Trove-api fails to start when deployed using packstack on RHEL 7.2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-trove
Version: 8.0 (Liberty)
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: 8.0 (Liberty)
Assignee: Alan Pevec
QA Contact: Luigi Toscano
URL:
Whiteboard:
Depends On: 1282928
Blocks: 1311555
TreeView+ depends on / blocked
 
Reported: 2016-06-28 14:02 UTC by Luigi Toscano
Modified: 2016-08-31 17:37 UTC (History)
15 users (show)

Fixed In Version: openstack-trove-4.0.0-5.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1311555
Environment:
Last Closed: 2016-08-31 17:37:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
squashed patches from liberty-rdo for rhos-8.0-rhel-7 (4.26 KB, patch)
2016-07-11 21:39 UTC, Alan Pevec
apevec: review? (hguemar)
Details | Diff


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 266977 0 None None None 2016-06-28 14:02:11 UTC
OpenStack gerrit 280258 0 None None None 2016-06-28 14:02:11 UTC
Red Hat Product Errata RHBA-2016:1792 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 8 Bug Fix Advisory 2016-08-31 21:35:27 UTC

Description Luigi Toscano 2016-06-28 14:02:11 UTC
+++ This bug was initially created as a clone of Bug #1311555 +++

+++ 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

--- Additional comment from Luigi Toscano on 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

--- Additional comment from Martin Magr on 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.

--- Additional comment from Ivan Chavero on 2016-06-02 00:31:16 EDT ---

This was already fixed, i added the most recent package so it can be checked by QE


--- Additional comment from Luigi Toscano on 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

--- Additional comment from Ivan Chavero on 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?

--- Additional comment from Luigi Toscano on 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.

--- Additional comment from Ivan Chavero on 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.

--- Additional comment from Luigi Toscano on 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 4 Nick Barcet 2016-06-29 20:41:18 UTC
Based on ​customer feedback, and the constant message that support for commercially available database was an absolute must from the almost all of the customers we surveyed, we have came to the conclusion that we should rather concentrate our effort in having successful partnerships around Trove rather than building a fully open-source solution that will not benefit our customers.

Comment 7 Alan Pevec 2016-07-11 21:39:48 UTC
Created attachment 1178548 [details]
squashed patches from liberty-rdo for rhos-8.0-rhel-7

Comment 9 Luigi Toscano 2016-07-28 08:11:34 UTC
After the sync, Trove services (deployed by packstack) are working out of the box.

Verified with:
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.3-1.el7ost.noarch
puppet-3.6.2-2.el7.noarch

openstack-trove-4.0.0-5.el7ost.noarch
openstack-trove-api-4.0.0-5.el7ost.noarch
openstack-trove-common-4.0.0-5.el7ost.noarch
openstack-trove-conductor-4.0.0-5.el7ost.noarch
openstack-trove-taskmanager-4.0.0-5.el7ost.noarch
python-trove-4.0.0-5.el7ost.noarch

Comment 11 errata-xmlrpc 2016-08-31 17:37:44 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://rhn.redhat.com/errata/RHBA-2016-1792.html


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