[Openstack-operators] Something really weird when PUT overwrites a file with same name but different content 1.4.8 - BUG ?

Leandro Reox leandro.reox at gmail.com
Mon Nov 5 15:07:52 UTC 2012 

A little update, this is happening updating headers too on existing objects
... were wondering whats wrong in our setup (a proxy ?) :S

An example setting a key-value on objects metadata (happens with any header)

curl -X HEAD -H "X-Auth-Token: ea5e7b70d58f4d45b0fc921e99b22f76" "
http://172.16.177.253:8080/v1/AUTH_1bf1f1b69a864abb84ed8a1bc82cff21/test-max/test"
-IHTTP/1.1 200 OK
*X-Object-Meta-Lean: CABEZA*
Last-Modified: Mon, 05 Nov 2012 14:59:04 GMT
Etag: d41d8cd98f00b204e9800998ecf8427e
Accept-Ranges: bytes
Content-Length: 0
Content-Type: application/octet-stream
X-Trans-Id: tx22818145f72b4ca3bf5f212721fecefc
Date: Mon, 05 Nov 2012 14:57:40 GMT

mvenesio at maxbox:~# curl -X PUT -H "X-Auth-Token:
ea5e7b70d58f4d45b0fc921e99b22f76" "
http://172.16.177.253:8080/v1/AUTH_1bf1f1b69a864abb84ed8a1bc82cff21/test-max/test"
-H "*X-Object-Meta-lean: PETERO" *-H "Content-Length: 0"
<html>
<head>
 <title>201 Created</title>
</head>
<body>
 <h1>201 Created</h1>
 <br /><br />



</body>
</html>mvenesio at maxbox:~#
mvenesio at maxbox:~#
mvenesio at maxbox:~# curl -X HEAD -H "X-Auth-Token:
ea5e7b70d58f4d45b0fc921e99b22f76" "
http://172.16.177.253:8080/v1/AUTH_1bf1f1b69a864abb84ed8a1bc82cff21/test-max/test"
-IHTTP/1.1 200 OK
*X-Object-Meta-Lean: CABEZA <<---- OLD HEADER :S*
Last-Modified: Mon, 05 Nov 2012 14:59:04 GMT
Etag: d41d8cd98f00b204e9800998ecf8427e
Accept-Ranges: bytes
Content-Length: 0
Content-Type: application/octet-stream
X-Trans-Id: txb2186e54462b473fabaf0342e0339a05
Date: Mon, 05 Nov 2012 14:57:59 GMT




On Mon, Nov 5, 2012 at 10:21 AM, Leandro Reox <leandro.reox at gmail.com>wrote:

> Hi guys,
>
> We're facing a really weird random issue on Swift 1.4.8, when we update an
> object that already exists with the same name, but different content,
> sometimes randomly the operation, dispites the proxy answer ( always 201
> created) doesnt succeed, and the object content doesnt get updated. But
> sometimes the operation succeed and the object content get overwritten.
>
> What we saw in terms of replication :
>
> - When the object doesnt get updated we dont see the .db file replicated
> accross the cluster
> - Whe the object overwrites OK we saw the 3 replicas of the object and the
> 3 db replicas propagating OK accross the hole cluster.
>
> This is happening with all the containers, and all the objects, randomly
>
> Things we already checked:
>
> - Ring files replicated ok acrros all proxies and all datanodes
> - Confs files ok
> - Memcached partners ok
> - Replication services, and all the other services running ok on all nodes
>
> Is this really and issue or we should DELETE and object previous uploading
> with the same name ?. We found this really weird (sounds like a bugs) cause
> succeeds randomly
>
> Best !
> Lean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121105/0dfc7066/attachment.html>

More information about the OpenStack-operators mailing list