[
https://issues.apache.org/jira/browse/HDDS-16626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Priyesh Karatha resolved HDDS-16626.
------------------------------------
Resolution: Duplicate
Its duplicate of HDDS-16624
> 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
> Assignee: Priyesh Karatha
> Priority: Major
>
> 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]
