[
https://issues.apache.org/jira/browse/HDDS-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Priyesh Karatha updated HDDS-16624:
-----------------------------------
Description:
*Problem*
When a PUT bucket lifecycle configuration request includes an
AbortIncompleteMultipartUpload.DaysAfterInitiation value that is not less than
the configured ozone.om.open.mpu.expire.threshold, OM correctly rejects the
request with InvalidRequest, but the error message's remediation is not
actionable:
Set daysAfterInitiation to a value less than 300s, or increase
ozone.om.open.mpu.expire.threshold
DaysAfterInitiation is defined by the S3 lifecycle API as a whole number of
days. There is no way to configure it in seconds through that API, so "set
daysAfterInitiation to a value less than 300s" gives the operator no valid
option to act on.
*Steps to Reproduce*
1. Configure ozone.om.open.mpu.expire.threshold=3
2. Submit a lifecycle configuration with
AbortIncompleteMultipartUpload.DaysAfterInitiation=1:
{code:java}
ozones3api put-bucket-lifecycle-configuration \
--bucket "$BUCKET" \
--lifecycle-configuration '{
"Rules": [{
"ID": "expiration-and-abort",
"Status": "Enabled",
"Filter": { "Prefix": "key1" },
"Expiration": { "Days": 1 },
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 }
}]
}' {code}
*Actual Result*
Request is rejected (correct), but the message suitiation below 300s, which is
impossible via the S3 lifecycle API's day-granularity field.
Expected Result
The request should still be rejected as InvalidRequest, but the message should:
- Explain that DaysAfterInitiation is whole-day gpressed in the threshold's
unit.
- Give an actionable remediation: either a concrete maximum day value that
would satisfy the current threshold, or instruction
to increase ozone.om.open.mpu.expire.threshold sfy it (threshold < 1 day).
was:
Problem
When a PUT bucket lifecycle configuration request includes an
AbortIncompleteMultipartUpload.DaysAfterInitiation value that is not less than
the configured ozone.om.open.mpu.expire.threshold, OM correctly rejects the
request with InvalidRequest, but the error message's remediation is not
actionable:
Set daysAfterInitiation to a value less than 300s, or increase
ozone.om.open.mpu.expire.threshold
DaysAfterInitiation is defined by the S3 lifecycle API as a whole number of
days. There is no way to configure it in seconds through that API, so "set
daysAfterInitiation to a value less than 300s" gives the operator no valid
option to act on.
Steps to Reproduce
1. Configure ozone.om.open.mpu.expire.threshold=3
2. Submit a lifecycle configuration with
AbortIncompleteMultipartUpload.DaysAfterInitiation=1:
ozones3api put-bucket-lifecycle-configuration \
--bucket "$BUCKET" \
--lifecycle-configuration '{
"Rules": [{
"ID": "expiration-and-abort",
"Status": "Enabled",
"Filter": \{ "Prefix": "key1" },
"Expiration": \{ "Days": 1 },
"AbortIncompleteMultipartUpload": { "DaysAf
}]
}'
Actual Result
Request is rejected (correct), but the message suitiation below 300s, which is
impossible via the S3 lifecycle API's day-granularity field.
Expected Result
The request should still be rejected as InvalidRequest, but the message should:
- Explain that DaysAfterInitiation is whole-day gpressed in the threshold's
unit.
- Give an actionable remediation: either a concrete maximum day value that
would satisfy the current threshold, or instruction
to increase ozone.om.open.mpu.expire.threshold sfy it (threshold < 1 day).
Fix
Updated validateAbortMpuDaysAgainstCleanupThreshotionSetRequest
(hadoop-ozone/ozone-manager) tocompute the largest whole-day
DaysAfterInitiation value still under the configured threshold and surface it
in the error message, falling back to an "increase the threshohreshold itself
is under one day.
> Misleading remediation in AbortIncompleteMultipartUpload lifecycle validation
> error message
> -------------------------------------------------------------------------------------------
>
> Key: HDDS-16624
> URL: https://issues.apache.org/jira/browse/HDDS-16624
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: S3
> Reporter: Priyesh Karatha
> Assignee: Priyesh Karatha
> Priority: Major
>
> *Problem*
> When a PUT bucket lifecycle configuration request includes an
> AbortIncompleteMultipartUpload.DaysAfterInitiation value that is not less
> than the configured ozone.om.open.mpu.expire.threshold, OM correctly rejects
> the request with InvalidRequest, but the error message's remediation is not
> actionable:
> Set daysAfterInitiation to a value less than 300s, or increase
> ozone.om.open.mpu.expire.threshold
> DaysAfterInitiation is defined by the S3 lifecycle API as a whole number of
> days. There is no way to configure it in seconds through that API, so "set
> daysAfterInitiation to a value less than 300s" gives the operator no valid
> option to act on.
> *Steps to Reproduce*
> 1. Configure ozone.om.open.mpu.expire.threshold=3
> 2. Submit a lifecycle configuration with
> AbortIncompleteMultipartUpload.DaysAfterInitiation=1:
> {code:java}
> ozones3api put-bucket-lifecycle-configuration \
> --bucket "$BUCKET" \
> --lifecycle-configuration '{
> "Rules": [{
> "ID": "expiration-and-abort",
> "Status": "Enabled",
> "Filter": { "Prefix": "key1" },
> "Expiration": { "Days": 1 },
> "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 }
> }]
> }' {code}
> *Actual Result*
> Request is rejected (correct), but the message suitiation below 300s, which
> is impossible via the S3 lifecycle API's day-granularity field.
> Expected Result
> The request should still be rejected as InvalidRequest, but the message
> should:
> - Explain that DaysAfterInitiation is whole-day gpressed in the threshold's
> unit.
> - Give an actionable remediation: either a concrete maximum day value that
> would satisfy the current threshold, or instruction
> to increase ozone.om.open.mpu.expire.threshold sfy it (threshold < 1 day).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
