[
https://issues.apache.org/jira/browse/HDDS-13740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gargi Jaiswal resolved HDDS-13740.
----------------------------------
Resolution: Abandoned
After testing and analysis of actual AWS S3 behaviour by [~ivanandika]
The behaviours are as follow:
* {*}Abort multipart upload that was initiated before (i.e. it exists
before){*}: This will return 204 to show that there is a successful abort
multipart upload before (idempotent)
* {*}Abort multipart upload that was never initiated (i.e. it does not
exist){*}: This will return 404 *None* since there was no successful abort
itself.
Since there is this distinction, we cannot simply returns 204 for non-existent
MPU key.
now the picture is clear to us as follows:
*AWS S3 behavior:*
* Abort an upload that existed → 204
* Abort the same upload again → 204 (idempotent)
* Abort the same upload again after 1 -2 days still returns -> 204, here we
don't know about the time period after which it will show 404 error for aborted
upload.
* Abort an upload that never existed → 404
*Current Ozone implementation:*
* After abort, entries are deleted from openKeyTable and multipartInfoTable
* A subsequent abort finds no metadata and throws
NO_SUCH_MULTIPART_UPLOAD_ERROR
* We can’t distinguish {{was aborted}} vs {{never existed}} because the
metadata is gone.
The current code correctly returns *404* for uploads that never existed. To
match {*}AWS’s idempotent 204{*}, we’d need to track aborted uploads, which
adds unnecessary complexity.
*To match AWS exactly, we would need to roighly follow below steps:*
* Track aborted uploads (e.g., a new table or flag in existing metadata)
* Check this record when NO_SUCH_MULTIPART_UPLOAD_ERROR is thrown
* Return 204 if previously aborted, 404 if never existed
* Implement cleanup/expiration for this tracking data
Since the grace period is not known to us that after how much it will throw 404
error, we can't fix the expiration time of previously aborted uploads and
defining this expiry by our own could again cause inconsistency.
I too prefer keeping the current behaviour unless AWS compatibility is
required. This is because ozone implementation of abort multipart uploads
removes entires from *openKeyTable and multipartInfoTable* means no metadata so
we can keep 404 error.
For further information please check the PR link for this.
> AbortMultipartUpload to ignore non-existent keys
> ------------------------------------------------
>
> Key: HDDS-13740
> URL: https://issues.apache.org/jira/browse/HDDS-13740
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: S3
> Affects Versions: 2.1.0
> Reporter: Wei-Chiu Chuang
> Assignee: Gargi Jaiswal
> Priority: Major
> Labels: pull-request-available
>
> Mint failed the following test against the latest master branch:
> {noformat}
> (3/15) Running aws-sdk-php tests ... FAILED in 4 seconds
> {
> "name": "aws-sdk-php",
> "function": "abortMultipartupload ( array $params = [] )",
> "args": {
> "Bucket": "aws-sdk-php-68e026c53a822",
> "Object": "obj1"
> },
> "duration": "25",
> "status": "FAIL",
> "error": "Error executing \"AbortMultipartUpload\" on
> \"http://host.containers.internal:9878/aws-sdk-php-68e026c53a822/obj1?uploadId=non-existent\";;
> AWS HTTP error: Client error: `DELETE
> http://host.containers.internal:9878/aws-sdk-php-68e026c53a822/obj1?uploadId=non-existent`
> resulted in a `404 Not Found` response:\n<?xml version=\"1.0\"
> encoding=\"UTF-8\"?>\n<Error>\n <Code>NoSuchUpload</Code>\n <Message>The
> specified multipart upload doe (truncated...)\n NoSuchUpload (client): The
> specified multipart upload does not exist. The upload ID might be invalid, or
> the multipart upload might have been aborted or completed. - <?xml
> version=\"1.0\" encoding=\"UTF-8\"?>\n<Error>\n <Code>NoSuchUpload</Code>\n
> <Message>The specified multipart upload does not exist. The upload ID might
> be invalid, or the multipart upload might have been aborted or
> completed.</Message>\n <Resource>non-existent</Resource>\n
> <RequestId>353a42ce-01c2-4914-a567-0f12efbd20b4</RequestId>\n</Error>\n"
> }
> {noformat}
> It looks like if AbortMultipartUpload request is given a non-existent key, it
> should respond 204 No Content (no exception) instead of 404.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
