Prince Raj created HDDS-16626:
---------------------------------
Summary: Misleading error message when DaysAfterInitiation is
below the configured MPU cleanup threshold
Key: HDDS-16626
URL: https://issues.apache.org/jira/browse/HDDS-16626
Project: Apache Ozone
Issue Type: Bug
Reporter: Prince Raj
h3. Description
While testing the {{PutBucketLifecycleConfiguration}} API for incomplete
multipart uploads, I observed that the validation correctly rejects a lifecycle
rule when {{AbortIncompleteMultipartUpload.DaysAfterInitiation}} exceeds the
configured multipart-upload cleanup threshold.
The lifecycle configuration used was:
{{}}
{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 } } ] }' \
--debug{code}
{{ }}
The cluster was configured with:
{{ozone.om.open.mpu.expire.threshold=300s}}
Since the lifecycle rule specifies {{DaysAfterInitiation=1}} day, while the MPU
cleanup threshold is configured to 300 seconds (5 minutes), the request is
correctly rejected because the background multipart-upload cleanup can remove
the upload before the lifecycle rule takes effect.
h3. Current Behavior
The API returns {{InvalidRequest}} with the following message:
{{}}
{code:java}
Invalid lifecycle configuration: rule 'abort-incomplete-mpu' has an
AbortIncompleteMultipartUpload action with daysAfterInitiation=1 day(s), which
is not less than the cluster MPU expire threshold
(ozone.om.open.mpu.expire.threshold=300s). The MultipartUploadCleanupService
will clean up the upload before the lifecycle rule fires, making the rule
ineffective. Set daysAfterInitiation to a value less than 300s, or increase
ozone.om.open.mpu.expire.threshold{code}
{{ }}
h3. Problem
The validation is correct, but the remediation suggested in the error message
is misleading.
{{AbortIncompleteMultipartUpload.DaysAfterInitiation}} is defined by the S3
lifecycle API as a whole number of {*}days{*}. The value cannot be configured
directly in seconds through the S3 lifecycle API.
Therefore, when:
{{ozone.om.open.mpu.expire.threshold=300s}}
the recommendation:
{{Set daysAfterInitiation to a value less than 300s}}
is not actionable through the S3 lifecycle API. There is no valid lifecycle
configuration in which {{DaysAfterInitiation}} can be set to a value such as
{{299}} seconds.
h3. Expected Behavior
The API should continue rejecting the lifecycle configuration with
{{{}InvalidRequest{}}}, since the configured MPU cleanup threshold can cause
the multipart upload to be removed before the lifecycle rule takes effect.
However, the error message should provide remediation that is consistent with
the units supported by the S3 lifecycle API.
For example:
{{Invalid lifecycle configuration: rule 'abort-incomplete-mpu' has
daysAfterInitiation=1 day(s), but the configured
ozone.om.open.mpu.expire.threshold is 300s.
The MultipartUploadCleanupService may clean up the upload before
the lifecycle rule takes effect.
DaysAfterInitiation must be specified as a whole number of days.
Increase ozone.om.open.mpu.expire.threshold to a value that allows
the configured lifecycle period, or adjust the lifecycle rule.}}
Alternatively, the message could explicitly explain the unit mismatch:
{{daysAfterInitiation must be configured in whole days; it cannot be
set to a value below the configured 300-second threshold using the
S3 lifecycle API. Increase ozone.om.open.mpu.expire.threshold to
accommodate the lifecycle period.}}
h3. Expected Result
* The existing validation behavior should remain unchanged.
* The API should continue returning {{InvalidRequest}} when the configured
lifecycle period cannot take effect before MPU cleanup.
* The error message should accurately describe the relationship between
{{DaysAfterInitiation}} and {{{}ozone.om.open.mpu.expire.threshold{}}}.
* The remediation guidance should account for the fact that
{{DaysAfterInitiation}} is specified in whole days, while the MPU cleanup
threshold is configured in seconds.
* The error message should not recommend setting {{DaysAfterInitiation}} to a
value in seconds that cannot be represented through the S3 lifecycle API.
h3. Reproduction
# Configure the MPU cleanup threshold to a value smaller than one day, for
example:
{{ozone.om.open.mpu.expire.threshold=300s}}
# Create a lifecycle configuration containing:
{{{
"AbortIncompleteMultipartUpload": \{
"DaysAfterInitiation": 1
}
}}}
# Submit the configuration using {{{}PutBucketLifecycleConfiguration{}}}.
# Observe that the API returns {{{}InvalidRequest{}}}.
# Observe that the validation error recommends configuring
{{DaysAfterInitiation}} to a value less than {{{}300s{}}}.
# Note that {{DaysAfterInitiation}} only accepts a whole number of days,
making this remediation invalid through the S3 lifecycle API.
h3. Impact
The validation prevents an ineffective lifecycle configuration, but the current
error message can mislead users into attempting a configuration that the S3
lifecycle API cannot represent.
The issue is therefore limited to the {*}accuracy and actionability of the
validation error message{*}, not the underlying validation logic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
