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:
Another issue is that Packstack didn't warn about this problem and finished successfully. Reported in bug #1020480.
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.
Please attach your /etc/swift/proxy-server.conf
Created attachment 813563 [details] proxy-server.conf
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...
Created attachment 813565 [details] output of "rpm -qa|sort"
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
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
# 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.
Yes we figured out ages ago to remove requirements.txt, it just wasn't done here, and the exit 0 compounded the issue.
I verified, openstack-swift-1.10.0-2.fc21 on Rawhide. Thanks Padraig.
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
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
Please see bug 1102926 for a possible fake-egg solution to this problem.