Bug 1214103 - rgw: objects with names starting with underscore become inaccessible after upgrading to Hammer
Summary: rgw: objects with names starting with underscore become inaccessible after up...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat Storage
Component: RGW
Version: 1.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 1.3.0
Assignee: John Wilkins
QA Contact: Harish NV Rao
URL:
Whiteboard:
Depends On: 1227358 1230832
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-22 00:41 UTC by Yehuda Sadeh
Modified: 2022-02-21 18:32 UTC (History)
11 users (show)

Fixed In Version: ceph-0.94.1-7.el7cp
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-24 15:52:21 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ceph Project Bug Tracker 11442 0 None None None Never
Red Hat Issue Tracker RHCEPH-3463 0 None None None 2022-02-21 18:32:18 UTC
Red Hat Product Errata RHBA-2015:1183 0 normal SHIPPED_LIVE Ceph bug fix and enhancement update 2015-06-24 19:49:46 UTC

Description Yehuda Sadeh 2015-04-22 00:41:26 UTC
Description of problem:

Objects that were created prior to Hammer that start with underscore cannot be accessed anymore. They are still listed, but cannot be found.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create object with name that starts with underscore (on pre-Hammer release)
2. Upgrade to Hammer
3. Access object

Actual results:

404 response


Expected results:

200 response


Additional info:
The culprit is an unintended behavior of the old code that is related to the rados object locator.

Comment 1 Ken Dreyer (Red Hat) 2015-04-22 21:35:43 UTC
Should this block the 1.3.0 release, or should ship a fix after 1.3.0 ships?

Comment 2 Harish NV Rao 2015-04-24 15:26:57 UTC
Is this going to be fixed in 1.3.0? 

If going to be fixed in 1.3.0 then the test plan for this fix is that repeat the steps mentioned above while upgrading from 1.2* to 1.3.0. If this plan is incorrect please let QE know.

Comment 3 Yehuda Sadeh 2015-04-24 16:09:05 UTC
Yes, this is going to be fixed in 1.3.0.

Comment 4 Harish NV Rao 2015-04-27 05:37:15 UTC
The QE test plan for this fix is:
 Repeat the steps mentioned in "Steps to Reproduce" while upgrading from 1.2* to 1.3.0. 

If this plan is incorrect then please let QE know the right plan.

Comment 8 Yehuda Sadeh 2015-06-11 18:36:02 UTC
yes

Comment 9 Hemanth Kumar 2015-06-12 10:48:52 UTC
Upgrade is failing - Once it gets fixed, I will be able to verify .. Depends on :- 1227358 & 1230832

Comment 10 Hemanth Kumar 2015-06-17 09:19:12 UTC
[root@magna116 conf.d]# cat s3test.py 
import boto
import boto.s3.connection

access_key = 'AM67GV605FNDBZ57TSLF'
secret_key = 'Q0eCc/oYm+AooD1VeraqfrAqS7abK5++ll55n7vW'

conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = 'magna116',
is_secure=False,
calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)

#bucket = conn.create_bucket('testt-bucket')

for bucket in conn.get_all_buckets():
	print "{name}\t{created}".format(
		name = bucket.name,
		created = bucket.creation_date,
)


#key = bucket.new_key('hello_hem.txt')
#key.set_contents_from_string('Hello World!')

#hello_key = bucket.get_key('hello_hem.txt')
#hello_key.set_canned_acl('public-read')


#key = bucket.new_key('_hello_hem.txt')
#key.set_contents_from_string('Hello ')

key = bucket.get_key('_hello_hem.txt')
key.get_contents_to_filename('/etc/httpd/conf.d/_hello_hem.txt')

[root@magna116 conf.d]# python s3test.py 
testt-bucket	2015-06-11T11:34:52.000Z

[root@magna116 conf.d]# ls
autoindex.conf  fastcgi.conf  _hello_hem.txt  README  rgw.conf  s3test.py  ssl.conf  userdir.conf  welcome.conf

[root@magna116 conf.d]# cksum _hello_hem.txt 
1904456389 6 _hello_hem.txt
[root@magna116 conf.d]# 


On the OSD Node :-

[root@gqas006 13.5_head]# cksum default.13418.1\\u\\u\\uhello\\uhem.txt_default.13418.1\\u\\uhello\\uhem.txt_head_BBFE29E5__d

1904456389 6 default.13418.1\u\u\uhello\uhem.txt_default.13418.1\u\uhello\uhem.txt_head_BBFE29E5__d

I was able to access/download the object file with "_" and also verified the cksum of both the files.. It was Fine

Moving to verified state

Comment 12 errata-xmlrpc 2015-06-24 15:52:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2015:1183


Note You need to log in before you can comment on or make changes to this bug.