Bug 1020449
| Summary: | Swift services not starting, requiring "xattr>=0.4" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Martina Kollarova <mkollaro> | ||||||
| Component: | openstack-swift | Assignee: | Pádraig Brady <pbrady> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Dafna Ron <dron> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 4.0 | CC: | abaron, apevec, derekh, hateya, mkollaro, ncredi, pbrady, yeylon, zaitcev | ||||||
| Target Milestone: | beta | Keywords: | Regression, TestBlocker | ||||||
| Target Release: | 4.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | storage | ||||||||
| 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-20 00:29:35 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Martina Kollarova
2013-10-17 17:03:06 UTC
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. |