Created attachment 1096183 [details] Stacktrace of the ImportError in the Manila API service Description of problem: When using Packstack to install Manila on OSP-8, at the completion of installation the Manila API Service is in Error status. The error does not cause the failure of the Packstack installation. It seems to be caused by an import error having to do with a Version attribute. See the attached traceback for more details. Version-Release number of selected component (if applicable): rpm -qa | grep manila python-manila-1.0.0-2.el7ost.noarch openstack-manila-share-1.0.0-2.el7ost.noarch python-manilaclient-1.4.0-1.el7ost.noarch openstack-manila-1.0.0-2.el7ost.noarch How reproducible: Appears to be every time you install Manila with packstack. Steps to Reproduce: 1. Install RHEL 7.2 on a host. 2. Download the RHOS-Release RPM and install the latest RHEL-OSP 8 puddle. 3. Install the "openstack-packstack" package. 4. Generate an answer file with "packstack --gen-answer-file=answers.txt" 5. Enable Manila by changing the value of CONFIG_MANILA_INSTALL to "y" 6. Install OSP-8 by running "packstack --answer-file=answers.txt" 7. Examine the status of the Manila API service by running "systemctl status openstack-manila-api" Actual results: The Manila API service fails to start and is in Error status. Expected results: The Manila API service shall start successfully on the completion of Packstack's install. Additional info: This was found using RHEL 7.2 and the OSP-8 latest stable daily poodle.
Created attachment 1096184 [details] Answer File used in Packstack to setup OSP-8
Dustin, check this bug that I forgot I opened exactly one month ago. It was almost the exact same problem, but with RDO: https://bugzilla.redhat.com/show_bug.cgi?id=1278918 Bottom line, update /etc/manila/api-paste.ini from upstream stable/liberty. See if that helps any.
Dave, you're spot on. It's the same issue and your suggestion fixed the issue I was having. I'll let the packager know to grab the latest version of the api-paste.ini file from the stable/liberty branch upstream. Thanks for the assist, Dave!
I appear to be hitting this issue with openstack-manila-share-1.0.0-2.el7ost.noarch, contrary to the assertion that it is fixed there: [root@dhcp148-134 ~(keystone_admin)]# rpm -qa \*manila\* openstack-manila-1.0.0-2.el7ost.noarch openstack-manila-share-1.0.0-2.el7ost.noarch python-manila-1.0.0-2.el7ost.noarch python-manilaclient-1.4.0-1.el7ost.noarch [root@dhcp148-134 ~(keystone_admin)]# grep ImportError /var/log/manila/api.log 2016-01-04 15:47:27.478 21672 CRITICAL manila [-] ImportError: <module 'manila.api.versions' from '/usr/lib/python2.7/site-packages/manila/api/versions.pyc'> has no 'Versions' attribute 2016-01-04 15:47:27.478 21672 ERROR manila raise ImportError("%r has no %r attribute" % (entry,attr)) 2016-01-04 15:47:27.478 21672 ERROR manila ImportError: <module 'manila.api.versions' from '/usr/lib/python2.7/site-packages/manila/api/versions.pyc'> has no 'Versions' attribute [root@dhcp148-134 ~(keystone_admin)]#
Hmm, I'll have to recheck this, then. Maybe I accidentally had a configuration file that was left over? I'll double check in the morning and get back to you, Tom!
Looks like it's still broken in the openstack-manila-1.0.0-2.el7ost.noarch package indeed. Seems to be with the api-paste.ini file that is included in the package. We will need to grab the version from the upstream stable/liberty branch located here: https://github.com/openstack/manila/blob/stable/liberty/etc/manila/api-paste.ini.
moving back to modified as version openstack-manila-1.0.1-1.el7ost is the build to be tested against.
Verified that the Manila-API service starts correctly using the version that Eric built in the 2016-01-05.2 poodle build.
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/RHEA-2016-0603.html