[
https://issues.apache.org/jira/browse/HDDS-17157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuo Huang updated HDDS-17157:
------------------------------
Description:
h3. Problem
Several subtasks let OM resolve the S3 volume itself when a request sets
{{{}assumeS3Context{}}}, so S3G no longer has to call {{getS3Volume}} first:
Each one adds its own {{OzoneManagerVersion}} entry. Since
{{TestOzoneManagerVersion}} requires consecutive numbers, the PRs keep clashing
(102 between [https://github.com/apache/ozone/pull/11449] and
[https://github.com/apache/ozone/pull/11574], then 103 between
[https://github.com/apache/ozone/pull/11479] and
https://github.com/apache/ozone/pull/11574) and have to be merged one at a
time. More subtasks are still coming.
h3. Proposal
Use one shared {{OzoneManagerVersion}} for all subtasks in this series instead
of one per operation. Since 102 isn't released yet, rename
{{S3_MULTIPART_UPLOAD_ABORT_CONTEXT}} to a generic name and have the remaining
subtasks reuse it.
h3. Caveat
A shared version only works if every operation behind it lands before the next
release.
Suggested by [~chungen]
was:
h3. Problem
Several subtasks let OM resolve the S3 volume itself when a request sets
{{{}assumeS3Context{}}}, so S3G no longer has to call {{getS3Volume}} first:
Each one adds its own {{OzoneManagerVersion}} entry. Since
{{TestOzoneManagerVersion}} requires consecutive numbers, the PRs keep clashing
(102 between https://github.com/apache/ozone/pull/11449 and
https://github.com/apache/ozone/pull/11574, then 103 between
https://github.com/apache/ozone/pull/11479
andhttps://github.com/apache/ozone/pull/11574) and have to be merged one at a
time. More subtasks are still coming.
h3. Proposal
Use one shared {{OzoneManagerVersion}} for all subtasks in this series instead
of one per operation. Since 102 isn't released yet, rename
{{S3_MULTIPART_UPLOAD_ABORT_CONTEXT}} to a generic name and have the remaining
subtasks reuse it.
h3. Caveat
A shared version only works if every operation behind it lands before the next
release.
Suggested by [~chungen]
> Use a single OzoneManagerVersion for S3 volume context resolution
> -----------------------------------------------------------------
>
> Key: HDDS-17157
> URL: https://issues.apache.org/jira/browse/HDDS-17157
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Shuo Huang
> Priority: Major
>
> h3. Problem
> Several subtasks let OM resolve the S3 volume itself when a request sets
> {{{}assumeS3Context{}}}, so S3G no longer has to call {{getS3Volume}} first:
>
> Each one adds its own {{OzoneManagerVersion}} entry. Since
> {{TestOzoneManagerVersion}} requires consecutive numbers, the PRs keep
> clashing (102 between [https://github.com/apache/ozone/pull/11449] and
> [https://github.com/apache/ozone/pull/11574], then 103 between
> [https://github.com/apache/ozone/pull/11479] and
> https://github.com/apache/ozone/pull/11574) and have to be merged one at a
> time. More subtasks are still coming.
> h3. Proposal
> Use one shared {{OzoneManagerVersion}} for all subtasks in this series
> instead of one per operation. Since 102 isn't released yet, rename
> {{S3_MULTIPART_UPLOAD_ABORT_CONTEXT}} to a generic name and have the
> remaining subtasks reuse it.
> h3. Caveat
> A shared version only works if every operation behind it lands before the
> next release.
> Suggested by [~chungen]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
