Bug #1830
RGW Swift Metadata Bug
0%
Description
I believe the rados gateway has a but in the way it's talking swift. When I ask it to list the objects in a container, objects with metadata appear to be sent back incorrectly causing some clients to become confused. I've attached a (very noisy) capture of the network traffic generated when running a python test script. The script connects to rackspace, creates an object, adds metadata, retrieves the object, and then loops over a list of objects in the container. It then does the same thing connected to benjamin instead of rackspace. The output from the script (it catches the KeyError to show us some detail about the broken object) and an excerpt from the network capture are reproduced below.
% ./virtualenv/bin/python test.py
Connecting to rackspace
syncing metadata
retreiving object directly:
kmtestobj1 -- metadata is: {'bar': 'quux'}
retreiving object list:
FreeBSD-8.1-RELEASE-i386-dvd1.iso
RIPLinux-11.4-non-X.iso
gpxe.iso
kmtestobj1
Connecting to benjamin
syncing metadata
retreiving object directly:
kmtestobj3 -- metadata is: {'bar': 'quux'}
retreiving object list:
kmtestobj2
***Object listing broken
[{u'bytes': 5,
u'content_type': u'application/octet-stream',
u'hash': u'"ad0234829205b9033196ba818f7a872b"',
u'last_modified': u'2011-12-09T18:36:42.000Z',
u'name': u'kmtestobj2'},
{u'bytes': 0,
u'hash': u'""',
u'last_modified': u'2011-12-09T18:36:43.000Z',
u'name': u'kmtestobj3'}]
Traceback (most recent call last):
File "test.py", line 54, in <module>
for o in ol:
File "/home/kylem/virtualenv/lib/python2.6/site-packages/cloudfiles/storage_object.py",
line 731, in getitem
return Object(self.container, object_record=self._objects[key])
File "/home/kylem/virtualenv/lib/python2.6/site-packages/cloudfiles/storage_object.py",
line 81, in init
self.content_type = object_record['content_type']
KeyError: 'content_type'
You can see that when I delve into why the object listing crashed, the
"kmtestobj3" object has bytes=0 hash="" and is completely missing the
content_type. The network capture confirms this; tcp stream 61 looks
like:
GET /swift/v1/foo?format=json HTTP/1.1
Host: objects.dreamhost.com
Accept-Encoding: identity
Content-Length: 0
X-Auth-Token: AUTH_rgwtk100000006b796c6d6172343a74657374696e6731aaa552702eeb5bc0b858e24eb0fcc52d69318e781dca98ad237b19806c696629afb4f5db
User-Agent: python-cloudfiles/1.7.9.3
HTTP/1.1 200 OK
Date: Fri, 09 Dec 2011 18:36:43 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
fe
[{"name":"kmtestobj2","hash":"\"ad0234829205b9033196ba818f7a872b\"","bytes":5,"content_type":"application\/octet-stream","last_modified":"2011-12-09T18:36:42.000Z"},{"name":"kmtestobj3","hash":"\"\"","bytes":0,"last_modified":"2011-12-09T18:36:43.000Z"}]
0
History
#1 Updated by Yehuda Sadeh almost 12 years ago
Ok, was able to reproduce it. Problem is in the swift specific update metadata operation. Fix should be pretty easy.
#2 Updated by Yehuda Sadeh almost 12 years ago
- Category set to 22
- Status changed from New to Resolved
Fixed, commit:3e323e6adbf87d794be39fd4f75c6626e8968ce1.
#3 Updated by John Spray almost 6 years ago
- Project changed from Ceph to rgw
- Category deleted (
22)
Bulk reassign of radosgw category to RGW project.