Project

General

Profile

Bug #11563

RadosGW regression: COPY doesn't preserve Content-Type

Added by Sylvain Munaut over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Urgent
Target version:
-
Start date:
05/07/2015
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
hammer
Regression:
Yes
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

Description

When creating an object with an explicit content-type then copying it to another key, the returned content-type is binary/octet-stream instead of what was set.

That definitely used to work fine in 0.87, but is now broken in 0.94. (Found it when running our own regression suite before updating prod)

issue-11563.py View (1.44 KB) Sylvain Munaut, 06/17/2015 03:04 PM


Related issues

Related to rgw - Bug #11639: Object copy bug Resolved 05/15/2015
Related to rgw - Bug #12370: test_s3.test_object_copy_canned_acl ... FAIL Resolved 07/16/2015
Related to rgw - Bug #13015: rgw: intra region copy does not preserve acl Resolved 09/09/2015
Copied to rgw - Backport #12199: RadosGW regression: COPY doesn't preserve Content-Type Resolved 05/07/2015

Associated revisions

Revision e41d97c8 (diff)
Added by Yehuda Sadeh over 3 years ago

rgw: fix assignment of copy obj attributes

Fixes: #11563
Clarify the confusing usage of set_copy_attrs() by switching the source and
destinatiion params (attrs, src_attrs). Switch to use attrs instead of
src_attrs afterwards. In one of the cases we originally used the wrong
variable.

Signed-off-by: Yehuda Sadeh <>

Revision 82ea02ab (diff)
Added by Yehuda Sadeh about 3 years ago

rgw: fix assignment of copy obj attributes

Fixes: #11563
Clarify the confusing usage of set_copy_attrs() by switching the source and
destinatiion params (attrs, src_attrs). Switch to use attrs instead of
src_attrs afterwards. In one of the cases we originally used the wrong
variable.

Signed-off-by: Yehuda Sadeh <>
(cherry picked from commit e41d97c8e38bb60d7e09e9801c0179efe7af1734)

History

#1 Updated by Samuel Just over 3 years ago

  • Project changed from Ceph to rgw
  • Category deleted (22)
  • Affected Versions deleted (v0.94)

#2 Updated by Sylvain Munaut over 3 years ago

Any news on this ?

Given that COPY is used when renaming objects (like if you do a streaming upload but you want the name of the object to be a sha256 of the name), it's pretty annoying to loose the metadata ...

#3 Updated by Sage Weil over 3 years ago

  • Priority changed from Normal to Urgent
  • Backport set to hammer

#4 Updated by Sage Weil over 3 years ago

  • Source changed from other to Community (user)

Might be fixed by #11639

#5 Updated by Abhishek Lekshmanan over 3 years ago

Is this in the swift or s3 API? In swift API there was a backport to hammer for COPY that may be the cause for this (https://github.com/ceph/ceph/pull/4568)

#6 Updated by Yehuda Sadeh over 3 years ago

  • Status changed from New to Can't reproduce

I cannot reproduce it on latest master.

#7 Updated by Yehuda Sadeh over 3 years ago

also can't reproduce it on hammer

#8 Updated by Sylvain Munaut over 3 years ago

I just updated my build to the latest commit of the 'hammer' branch ( 3e8d60a80ce31860eac76a1f6489a35e1795a0c0 ) and I still have the issue.

See the attached python script to reproduce (using boto, edit the top part with credentials and host/port).

And this is all using the S3 API.

#9 Updated by Sylvain Munaut over 3 years ago

Also tried pulling the commit for #11639 into my branch, didn't change anything. Also that commit is only for same bucket copy, but the content-type (and other metadata) should be kept even when copying to other bucket. (unless new metadata are provided in the COPY call)

#10 Updated by Yehuda Sadeh over 3 years ago

  • Status changed from Can't reproduce to Verified

ok, managed to reproduce using your test. The key difference from my tests is that the object size also needs to be > 512k.

#11 Updated by Yehuda Sadeh over 3 years ago

  • Status changed from Verified to Need Review
  • Assignee set to Orit Wasserman

#12 Updated by Sylvain Munaut over 3 years ago

I cherry picked 1a6c3e760b1e2c1f4698009e70fd6cd1515ec722 over the recent hammer branch ( 3e8d60a80ce31860eac76a1f6489a35e1795a0c0 ) but the behavior didn't change.

Do I need any other commits ?

#13 Updated by Yehuda Sadeh over 3 years ago

I tested it again now and it works for me (tested commit:e41d97c8e38bb60d7e09e9801c0179efe7af1734). However, note that there's an issue with your test script, that when you check for the copy key, you're doing b.new_key() instead of b.get_key().

#14 Updated by Sylvain Munaut over 3 years ago

You're right my bad, the fix seems to work.

When running my full test suite, it now passes correctly with the fix. Seems I made a small mistake when writing the small .py test above and changing it to get_key() works.

#15 Updated by Yehuda Sadeh over 3 years ago

  • Status changed from Need Review to Pending Backport

#16 Updated by Yehuda Sadeh over 3 years ago

  • Assignee changed from Orit Wasserman to Loic Dachary

#17 Updated by Loic Dachary over 3 years ago

  • Description updated (diff)

#18 Updated by Loic Dachary about 3 years ago

  • Assignee changed from Loic Dachary to Orit Wasserman

Assigning Orit to record who was assigned the issue originally ( I still care for the backport of course ;-)

#19 Updated by Sylvain Munaut about 3 years ago

How is that not in 0.94.3 ?!?

Patch has been done for 3 month and it fixes a regression ...

#20 Updated by Yehuda Sadeh about 3 years ago

Sorry for the time it takes. It fixed a regression but also introduced one, so we need to make sure everything works correctly now.

#21 Updated by Loic Dachary about 3 years ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF