Description of problem: GET errors out with an improper message, [root@RHSSA1 rpms-ready]# curl -v -X GET -H 'X-Auth-Token: AUTH_tk324e52c791cb41b6b80eb91320e05a9f' http://127.0.0.1:8080/v1/AUTH_test/cont1/dir1 * About to connect() to 127.0.0.1 port 8080 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET /v1/AUTH_test/cont1/dir1 HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: 127.0.0.1:8080 > Accept: */* > X-Auth-Token: AUTH_tk324e52c791cb41b6b80eb91320e05a9f > < HTTP/1.1 503 Internal Server Error < Content-Type: text/html; charset=UTF-8 < Content-Length: 0 < Date: Mon, 20 Feb 2012 13:35:29 GMT < * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 Version-Release number of selected component (if applicable): 3.3.0qa22 How reproducible: Steps to Reproduce: 1.create some subdirs 2.do GET for one of the subdirs 3. Actual results: Expected results: Additional info:
on original swift the error message is, < HTTP/1.1 404 Not Found < Content-Length: 154 < Content-Type: text/html; charset=UTF-8 < Date: Thu, 05 Apr 2012 12:18:32 GMT < <html> <head> <title>404 Not Found</title> </head> <body> <h1>404 Not Found</h1> The resource could not be found.<br /><br /> </body> * Connection #0 to host 127.0.0.1 left intact
This will be fixed post 3.3 release.
This bug is no longer observed in gluster-swift grizzly but is observable in gluster-swift master(havana).
Grizzly based system with "newvol" as a Gluster volume name in backend. Prepared a container and a sub directory on it. There are no errors observed on Grizzly based system. First message shows the directory type of object creation. and then a GET on this. [root@crisbud ~]# curl -v -X PUT -H 'X-Content-Type: applicatione/directory' -H 'Content-Length: 0' http://127.0.0.1:8080/v1/AUTH_newvol/container1/dir2 * About to connect() to 127.0.0.1 port 8080 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > PUT /v1/AUTH_newvol/container1/dir2 HTTP/1.1 > User-Agent: curl/7.27.0 > Host: 127.0.0.1:8080 > Accept: */* > X-Content-Type: applicatione/directory > Content-Length: 0 > < HTTP/1.1 201 Created < Last-Modified: Mon, 16 Sep 2013 09:10:28 GMT < Content-Length: 0 < Etag: d41d8cd98f00b204e9800998ecf8427e < Content-Type: text/html; charset=UTF-8 < X-Trans-Id: txf8e410cfafbf4878bb5f55e26d6898a8 < Date: Mon, 16 Sep 2013 09:10:28 GMT < * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 [root@crisbud ~]# curl -v -X GET http://127.0.0.1:8080/v1/AUTH_newvol/container1/dir2 * About to connect() to 127.0.0.1 port 8080 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET /v1/AUTH_newvol/container1/dir2 HTTP/1.1 > User-Agent: curl/7.27.0 > Host: 127.0.0.1:8080 > Accept: */* > < HTTP/1.1 200 OK < Content-Length: 0 < Accept-Ranges: bytes < Last-Modified: Mon, 16 Sep 2013 09:10:28 GMT < Etag: d41d8cd98f00b204e9800998ecf8427e < X-Timestamp: 1379322628.36331 < Content-Type: application/octet-stream < X-Trans-Id: txd325d15295ea4ffeab5b9d89dd87c3a7 < Date: Mon, 16 Sep 2013 09:10:39 GMT < * Connection #0 to host 127.0.0.1 left intact * Closing connection #0
HAVANA based system also did not show any errors while performing above mentioned repro stesp. [root@vm2 /]# curl -v -X PUT -H 'X-Content-Type: applicatione/directory' -H 'Content-Length: 0' http://127.0.0.1:8080/v1/AUTH_test2/container1/dir1 * About to connect() to 127.0.0.1 port 8080 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > PUT /v1/AUTH_test2/container1/dir1 HTTP/1.1 > User-Agent: curl/7.27.0 > Host: 127.0.0.1:8080 > Accept: */* > X-Content-Type: applicatione/directory > Content-Length: 0 > < HTTP/1.1 201 Created < Last-Modified: Mon, 16 Sep 2013 09:02:09 GMT < Content-Length: 0 < Etag: d41d8cd98f00b204e9800998ecf8427e < Content-Type: text/html; charset=UTF-8 < X-Trans-Id: txaf0fcbe6c3234f028877e-005236c911 < Date: Mon, 16 Sep 2013 09:02:09 GMT < * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 [root@vm2 /]# curl -v -X GET http://127.0.0.1:8080/v1/AUTH_test2/container1/dir1 * About to connect() to 127.0.0.1 port 8080 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET /v1/AUTH_test2/container1/dir1 HTTP/1.1 > User-Agent: curl/7.27.0 > Host: 127.0.0.1:8080 > Accept: */* > < HTTP/1.1 200 OK < Content-Length: 0 < Accept-Ranges: bytes < Last-Modified: Mon, 16 Sep 2013 09:02:09 GMT < Etag: d41d8cd98f00b204e9800998ecf8427e < X-Timestamp: 1379322129.73821 < Content-Type: application/octet-stream < X-Trans-Id: txb7a0adbe0d9d45bda0961-005236c91d < Date: Mon, 16 Sep 2013 09:02:21 GMT < * Connection #0 to host 127.0.0.1 left intact * Closing connection #0
Moving ahead: on Grizzly based systems: If you directly create a subdirectory on a backend gluster volume as directed below there used to be error thrown as below. [root@vm2 /]# cd /mnt/gluster-object/test2/ [root@vm2 test2]# ls container1 [root@vm2 test2]# cd container1/ [root@vm2 container1]# ls dir1 [root@vm2 container1]# mkdir newdir [root@vm2 container1]# cd [root@vm2 ~]# curl -v -X GET http://127.0.0.1:8080/v1/AUTH_test2/container1/newdir [root@vm2 ~]# curl -v -X GET http://127.0.0.1:8080/v1/AUTH_test2/container1/newdir * About to connect() to 127.0.0.1 port 8080 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET /v1/AUTH_test2/container1/newdir HTTP/1.1 > User-Agent: curl/7.27.0 > Host: 127.0.0.1:8080 > Accept: */* > < HTTP/1.1 200 OK < Content-Length: 0 < Accept-Ranges: bytes < Last-Modified: Mon, 16 Sep 2013 09:10:39 GMT < Etag: d41d8cd98f00b204e9800998ecf8427e < X-Timestamp: 1379322639.30244 < Content-Type: application/directory < X-Trans-Id: tx8a96afb882784eb0b5175-005236cb1a < Date: Mon, 16 Sep 2013 09:10:50 GMT < * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 But now this has been fixed in HAVANA, latest of G4S (master).
Marking this bug as fixed in latest master, upstream in G4S with change : http://review.gluster.org/#/c/5511/
The bug is fixed in HAVANA as well. changing it to ON_QA as latest downstream gluster-swift is present.
Never seen the problem after RHS2.1-GA(Grizzly based). Marking this Verified.
Fixed in RHsS 2.1