Bug #40815
opens3cmd modify fails with ceph
0%
Description
s3cmd modify is supposed to provide the ability to modify user metadata on an existing s3 object.
So. I have an existing bucket "test" which for this test probably had versioning suspended. (I think the versioning doesn't matter), and an existing object "after.dat" (that happened to have been created when versioning was enabled.):
s3cmd modify s3://test/after.dat --add-header=x-amz-meta-barberry:red
This showed no error, yet the metadata did not change.
Examination of what happened shows this request,
"PUT /test/after.dat HTTP/1.1\r\nHost: livosteus.eng.arb.redhat.com\r\nAccept-Encoding: identity\r\nContent-Length: 0\r\nx-rgw-object-type: Normal\r\nx-amz-meta-barberry: red\r\ncontent-type: binary/octet-stream\r\nx-amz-copy-source: /test/after.dat\r\nx-amz-metadata-directive: REPLACE\r\nx-amz-date: Wed, 17 Jul 2019 20:04:47 +0000\r\nAuthorization: AWS d809bd6d89dc4779a81a4f5254aa7584:VMgyj1SUIp5TUHf6W4o9hHEDE6Y=\r\n\r\n"
and this error result,
"HTTP/1.1 403 Forbidden\r\nContent-Length: 185\r\nx-amz-request-id: tx00000000000000000003a-005d2f7f5f-106d-default\r\nAccept-Ranges: bytes\r\nContent-Type: application/xml\r\nDate: Wed, 17 Jul 2019 20:04:47 GMT\r\n\r\n"
So. 3 problems:
1/ I don't see any logic in ceph to handle "x-amz-metadata-directive: REPLACE". (And I'm not entirely sure just why s3cmd thinks that's right).
2/ I'm not sure why ceph rejected this with "Forbidden" - I suspect it should have tried to do something.
3/ surely s3cmd should have complained about the error it got?
Updated by Matt Benjamin over 4 years ago
- Assignee set to Marcus Watts
@Marcus Sorensen, can you rca and fix?
Matt