Bug 1020449 - Swift services not starting, requiring "xattr>=0.4"
Swift services not starting, requiring "xattr>=0.4"
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-swift (Show other bugs)
4.0
Unspecified Unspecified
unspecified Severity urgent
: beta
: 4.0
Assigned To: Pádraig Brady
Dafna Ron
storage
: Regression, TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-17 13:03 EDT by Martina Kollarova
Modified: 2016-01-04 09:43 EST (History)
9 users (show)

See Also:
Fixed In Version: openstack-swift-1.10.0-2.el6ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-19 19:29:35 EST
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)
proxy-server.conf (1.08 KB, text/plain)
2013-10-17 18:31 EDT, Martina Kollarova
no flags Details
output of "rpm -qa|sort" (24.12 KB, text/plain)
2013-10-17 18:39 EDT, Martina Kollarova
no flags Details

  None (edit)
Description Martina Kollarova 2013-10-17 13:03:06 EDT
Description of problem:
Swift services (proxy, account, container, object) fail to start with the following error: 

# swift-init container start
Starting container-server...(/etc/swift/container-server.conf)
Error trying to load config from /etc/swift/container-server.conf: xattr>=0.4

The package pyxattr-0.5 is installed, but apparently xattr != pyxattr. Installing xattr from pip fails:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 75: ordinal not in range(128)

Version-Release number of selected component (if applicable):
Both RHOS4 (puddle 2013-10-15.1) and RDO Havana on RHEL 6.5

openstack-swift-account-1.10.0-0.2.rc1.el6ost.noarch
openstack-swift-proxy-1.10.0-0.2.rc1.el6ost.noarch
openstack-swift-1.10.0-0.2.rc1.el6ost.noarch
openstack-swift-container-1.10.0-0.2.rc1.el6ost.noarch
openstack-swift-plugin-swift3-1.0.0-0.20120711git.1.el6ost.noarch
openstack-swift-object-1.10.0-0.2.rc1.el6ost.noarch
pyxattr-0.5.0-1.el6.x86_64
openstack-packstack-2013.2.1-0.6.dev763.el6ost.noarch

How reproducible:
always

Steps to Reproduce:
1. swift-init proxy start
 (or swift-init object start, etc)


Actual results:
# swift-init proxy start
Starting proxy-server...(/etc/swift/proxy-server.conf)
Error trying to load config from /etc/swift/proxy-server.conf: xattr>=0.4

Expected results:


Additional info:
Comment 2 Martina Kollarova 2013-10-17 14:24:41 EDT
Another issue is that Packstack didn't warn about this problem and finished successfully. Reported in bug #1020480.
Comment 3 Alan Pevec 2013-10-17 18:11:24 EDT
xattr has been in Swift's requirements.txt and tools/pip-requires (<=Grizzly) since ever and, reportedly, 1.9.1 RPM version doesn't have this issue, so I'm not sure what changed in 1.10.0-0.2.rc1 to trigger this.
Comment 4 Alan Pevec 2013-10-17 18:22:52 EDT
Please attach your /etc/swift/proxy-server.conf
Comment 5 Martina Kollarova 2013-10-17 18:31:27 EDT
Created attachment 813563 [details]
proxy-server.conf
Comment 6 Pete Zaitcev 2013-10-17 18:35:23 EDT
I keep hitting this on and off and it's extremely annoying that I have no
clue why this keeps happening. I meant to investigate what is happening
for a long time.

Maybe I screwed up the magic dependencies patch when I rebased to 1.9.1
and Padraig didn't notice when he went to 1.10.0 RC.

BTW, Martina, could you please save "rpm -a|sort" for me too? Otherwise
it's impossible to reproduce once I have it fixed...
Comment 7 Martina Kollarova 2013-10-17 18:39:45 EDT
Created attachment 813565 [details]
output of "rpm -qa|sort"
Comment 8 Alan Pevec 2013-10-17 18:48:11 EDT
ok, it fails with default proxy-server.conf from RPM, interestingly enough, swift-init happily returns 0 and hence service openstack-swift-proxy start was happily showing Starting swift-proxy-server:                       [  OK  ]

# swift-init proxy start; echo $?
Starting proxy-server...(/etc/swift/proxy-server.conf)
Error trying to load config from /etc/swift/proxy-server.conf: xattr>=0.4

0
Comment 9 Alan Pevec 2013-10-17 19:28:31 EDT
Workaround is to rm /usr/lib/python2.6/site-packages/swift-1.10.0.rc1-py2.6.egg-info/requires.txt
Looks like sed oneliner[1] is not enough, we should just kill requirements.txt completely during rpm build. Suggested approach would be to use patch to remove it link in [2] - that way you'll be warned when upstream changes their dependecies, during rebase you'd get conflicts.


[1] http://pkgs.fedoraproject.org/cgit/openstack-swift.git/tree/openstack-swift.spec#n171

[2] http://pkgs.fedoraproject.org/cgit/python-keystoneclient.git/tree/0001-Remove-runtime-dependency-on-python-pbr.patch
Comment 10 Martina Kollarova 2013-10-18 07:09:35 EDT
# swift-init proxy start; echo $?
Starting proxy-server...(/etc/swift/proxy-server.conf)
Error trying to load config from /etc/swift/proxy-server.conf: xattr>=0.4

0
# swift-init proxy status; echo $?
No proxy-server running
1


The workaround helped, thanks.
Comment 11 Pádraig Brady 2013-10-18 07:10:44 EDT
Yes we figured out ages ago to remove requirements.txt,
it just wasn't done here, and the exit 0 compounded the issue.
Comment 12 Pete Zaitcev 2013-10-20 12:06:18 EDT
I verified, openstack-swift-1.10.0-2.fc21 on Rawhide. Thanks Padraig.
Comment 16 Dafna Ron 2013-11-19 13:45:25 EST
after install server is up:

root@nott-vdsa ~]# swift-init proxy status
proxy-server running (12948 - /etc/swift/proxy-server.conf)

[root@nott-vdsa ~]# rpm -qa |grep swift 
openstack-swift-1.10.0-2.el6ost.noarch
openstack-swift-plugin-swift3-1.0.0-0.20120711git.1.el6ost.noarch
python-swiftclient-1.6.0-1.el6ost.noarch
openstack-swift-proxy-1.10.0-2.el6ost.noarch
Comment 18 errata-xmlrpc 2013-12-19 19:29:35 EST
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.

http://rhn.redhat.com/errata/RHEA-2013-1859.html
Comment 19 Pete Zaitcev 2014-05-29 17:09:32 EDT
Please see bug 1102926 for a possible fake-egg solution to this problem.

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