xichen01 commented on code in PR #11229:
URL: https://github.com/apache/ozone/pull/11229#discussion_r4274424947
##########
hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/util/S3Consts.java:
##########
@@ -131,6 +131,11 @@ public final class S3Consts {
/** Request header carrying the list of object attributes to return. */
public static final String OBJECT_ATTRIBUTES_HEADER =
"x-amz-object-attributes";
+ // S3 storage class values passed via the `x-amz-storage-class` request
header.
+ public static final String S3_STORAGE_CLASS_STANDARD = "STANDARD";
+ public static final String S3_STORAGE_CLASS_STANDARD_IA = "STANDARD_IA";
+ public static final String S3_STORAGE_CLASS_GLACIER = "GLACIER";
+
Review Comment:
@devmadhuu
> @Gargi-jais11 Agree that fields should be optional. On your question
"Where does the reverse direction get the policy?", this patch
https://github.com/apache/ozone/pull/11377 keys can override the bucket default.
The reverse direction reads KeyInfo.storagePolicy and never fills a missing
value from the bucket. So SetBucketProperty to COLD won't relabel existing
objects as GLACIER. KeyInfo.storagePolicy is only set when a policy was
explicitly requested on the write, so a key that inherited its policy has null,
and null falls back to the replication-based mapping.
Once the storage policy feature for OM is launched, every Key will have a
`storagePolicy`. The priority order is as follows:
1. Explicitly specified when the key is created;
2. If not specified for the key, the bucket’s storage policy is used (if not
null);
3. If not specified when the key is created and the bucket’s storage policy
is also null, `OzoneStoragePolicy.getDefaultPolicy()` is used;
can see:
https://github.com/apache/ozone/pull/11377/changes#diff-2841a017f8d700d802af1b1c49fea9ca281098728796384f5b2e79c23f09ab65R998
Thus, for keys created before the storage policy feature was launched, the
`storagePolicy` is null; after the feature is launched, every `Key` will have a
`storagePolicy`.
It can be understood that once a storage policy is specified, it will not
change (unless you set it manually).
- The `storagePolicy` attribute of a `Key` is independent and will not
change based on changes to the bucket’s `storagePolicy`.
- Even if a fallback occurs during key write (when
`allowFallbackStoragePolicy=true`), this will not change the key’s
`storagePolicy`. Fallback is an SCM-side behavior and does not affect the key’s
`storagePolicy`
Therefore, the reverse map simply retrieves the storage policy directly
based on the key (the same applies to replication type).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
