Bug 795614

Summary:	object-strorage: GET errors out with improper error message
Product:	[Community] GlusterFS	Reporter:	Saurabh <saujain>
Component:	object-storage	Assignee:	Thiago da Silva <thiago>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David J. Mac Donald <david.macdonald>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	pre-release	CC:	bugs, gluster-bugs, mzywusko, ppai, rwheeler, vbellur
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	852811 (view as bug list)		Environment:
Last Closed:	2015-11-20 06:22:58 UTC	Type:	---
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:
Bug Blocks:	852811

Description Saurabh 2012-02-21 04:01:14 UTC

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:

Comment 1 Saurabh 2012-04-05 12:16:41 UTC

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

Comment 2 Junaid 2012-05-21 05:52:42 UTC

This will be fixed post 3.3 release.

Comment 4 Prashanth Pai 2013-08-26 11:49:24 UTC

This bug is no longer observed in gluster-swift grizzly but is observable in gluster-swift master(havana).

Comment 5 crisbud@redhat.com 2013-09-16 09:14:53 UTC

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

Comment 6 crisbud@redhat.com 2013-09-16 09:16:27 UTC

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

Comment 7 crisbud@redhat.com 2013-09-16 09:19:38 UTC

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).

Comment 8 crisbud@redhat.com 2013-09-16 09:22:25 UTC

Marking this bug as fixed in latest master, upstream in G4S with change : 

http://review.gluster.org/#/c/5511/

Comment 9 crisbud@redhat.com 2013-12-18 06:50:23 UTC

The bug is fixed in HAVANA as well. changing it to ON_QA as latest downstream gluster-swift is present.

Comment 10 pushpesh sharma 2014-01-27 07:26:25 UTC

Never seen the problem after RHS2.1-GA(Grizzly based). Marking this Verified.

Comment 14 Prashanth Pai 2015-11-20 06:22:58 UTC

Fixed in RHsS 2.1