Project

General

Profile

Actions

Bug #9039

closed

Using COPY on radosgw to copy object from one bucket to another that's in another pool should either copy data or be rejected

Added by Sylvain Munaut over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
firefly
Regression:
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Currently if you copy an object from a bucket to another one which is in another rados pool, things will just break. Copy is accepted but you can't re-read the object.

Either the data should be copied. Or the operation should be refused at the very least.

Actions #1

Updated by Ian Colle over 9 years ago

  • Assignee set to Yehuda Sadeh
Actions #2

Updated by Yehuda Sadeh over 9 years ago

  • Priority changed from Normal to High
Actions #3

Updated by Yehuda Sadeh over 9 years ago

That sounds like an issue with the new (firefly) manifest.

Actions #4

Updated by Sylvain Munaut over 9 years ago

Really ? I didn't see anything in the code that checked whether the destination bucket was in the same pool or not and would even try to do the right thing, but maybe I missed it.

Actions #5

Updated by Yehuda Sadeh over 9 years ago

The problem is that it is implicitly assumed with the new manifest that the tail is going to reside at the same pool where the head is. This is an oversight and should be fixed. I think that a first go at this will be to do a data copy as you suggested. We can later improve the manifest.

Actions #6

Updated by Sylvain Munaut over 9 years ago

Well, I think data copy is the right thing to do. If I put bucket in different pool is because they're configured differently (like more replication or using erasure or slower storage) and when copying a file to a bucket with this other pool, I excpect to get the specs of whatever spec I'm copying TO and the one I'm copying FROM.

Actions #7

Updated by Sage Weil over 9 years ago

  • Status changed from New to Pending Backport
  • Source changed from other to Development
  • Backport set to firefly

the restriping fix patches also need to go to dumpling...

Actions #8

Updated by Yehuda Sadeh over 9 years ago

The restriping tool never made it to dumpling. It actually isn't even in firefly.

Actions #9

Updated by Sage Weil over 9 years ago

  • Status changed from Pending Backport to 12

not sure what the state of this bug is then.. yehuda?

Actions #10

Updated by Yehuda Sadeh over 9 years ago

sent a pull request now, #2632

Actions #11

Updated by Yehuda Sadeh over 9 years ago

  • Status changed from 12 to Pending Backport
Actions #12

Updated by Yehuda Sadeh over 9 years ago

  • Status changed from Pending Backport to Resolved
Actions

Also available in: Atom PDF