+++ 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
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
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.
This was already fixed, i added the most recent package so it can be checked by QE
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
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?
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.
(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.
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?
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