Bug 1135135
| Summary: | python-swiftclient v2.1.0-2.el7ost fails to create containers when openstack is integrated with radosgw. | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | JuanJose Galvez <jgalvez> |
| Component: | ceph | Assignee: | Josh Durgin <jdurgin> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Warren <wusui> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 5.0 (RHEL 7) | CC: | amarango, icolle, jdurgin, jefbrown, jeff.dexter, lhh, mbenjamin, nlevine, scohen, sreber, srevivo |
| Target Milestone: | --- | Keywords: | ZStream |
| Target Release: | 5.0 (RHEL 7) | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-22 13:24:23 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: | |||
| Bug Depends On: | 1169530, 1176181, 1176186, 1183150, 1202548, 1206465, 1232881 | ||
| Bug Blocks: | |||
|
Description
JuanJose Galvez
2014-08-28 22:14:04 UTC
JJ, do you have logs of the requests generated by swiftclient 2.0.x and 2.1.0? I don't see any obvious changes that could cause this in the commit log. Hi Josh, I managed to reproduce this. What kind of logs are you looking for exactly? When creating a container with 2.1.0 i get the following in apache error log: [Tue Oct 07 16:04:05 2014] [error] [client 10.99.118.30] Invalid Content-Length And apache returns a 400. The request never hits the radosgw (no logs). Output: [root@rhel1 log]# swift -v -V 2.0 -A http://10.214.133.14:5000/v2.0 -U admin:admin -K admin post test_container_keystone_1 Container POST failed: http://burnupi03.front.sepia.ceph.com/swift/v1/test_container_keystone_1 400 Bad Request [first 60 chars of response] <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><he Let me know if you need anything else. I'm unable to reproduce this using the upstream swift client 2.1.0 (or 2.3.1). I also found that Horizon, was trying to add an additional "/" when it gets the containers, causing it to fail with the object store. 015-03-12 14:59:28,583 27137 ERROR swiftclient Container HEAD failed: http://192.168.9.4/swift/v1///test1 404 Not Found Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/swiftclient/client.py", line 1192, in _retry rv = func(self.url, self.token, *args, **kwargs) File "/usr/lib/python2.7/site-packages/swiftclient/client.py", line 628, in head_container http_response_content=body) ClientException: Container HEAD failed: http://192.168.9.4/swift/v1///test1 404 Not Found Modified the swift api code in horizon to: def swift_get_container(request, container_name, with_data=True): if with_data: headers, data = swift_api(request).get_object(container_name, "") else: data = None headers = swift_api(request).head_container(container_name) timestamp = None is_public = False public_url = None try: is_public = GLOBAL_READ_ACL in headers.get('x-container-read', '') if is_public: swift_endpoint = base.url_for(request, 'object-store', endpoint_type='publicURL') - public_url = swift_endpoint + '/' + urlparse.quote(container_name) + public_url = swift_endpoint + urlparse.quote(container_name) ts_float = float(headers.get('x-timestamp')) timestamp = timeutils.iso8601_from_timestamp(ts_float) except Exception: pass container_info = { 'name': container_name, 'container_object_count': headers.get('x-container-object-count'), 'container_bytes_used': headers.get('x-container-bytes-used'), 'timestamp': timestamp, 'data': data, 'is_public': is_public, 'public_url': public_url, } return Container(container_info) Hi Matt, We are bug scrubbing and was wondering if this is still relavent? Can we close this bug or do we need to have someone in QE look at it? Jeff Feel free to reopen with new data... Sean The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |