devmadhuu commented on code in PR #11229: URL: https://github.com/apache/ozone/pull/11229#discussion_r4397420933
########## hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/util/S3StorageClassResolver.java: ########## @@ -0,0 +1,187 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.hadoop.ozone.s3.util; + +import static org.apache.hadoop.ozone.s3.S3GatewayConfigKeys.OZONE_S3G_STORAGE_CLASS_REDUCED_REDUNDANCY_STORAGE_POLICY; +import static org.apache.hadoop.ozone.s3.S3GatewayConfigKeys.OZONE_S3G_STORAGE_CLASS_STANDARD_STORAGE_POLICY; + +import jakarta.annotation.Nonnull; +import jakarta.annotation.Nullable; +import java.util.Locale; +import org.apache.commons.lang3.StringUtils; +import org.apache.hadoop.hdds.client.ECReplicationConfig; +import org.apache.hadoop.hdds.client.OzoneStoragePolicy; +import org.apache.hadoop.hdds.client.RatisReplicationConfig; +import org.apache.hadoop.hdds.client.ReplicationConfig; +import org.apache.hadoop.hdds.client.StoragePolicy; +import org.apache.hadoop.hdds.conf.ConfigurationSource; +import org.apache.hadoop.hdds.protocol.proto.HddsProtos.ReplicationType; + +/** + * Maps between S3 storage class names and Ozone replication and storage policy. + * + * <p>The two directions are deliberately not symmetric: + * <ul> + * <li><b>Forward</b> (request header to Ozone) is strict. An unknown name is the client's mistake + * and is rejected.</li> + * <li><b>Reverse</b> (stored key to response header) never fails. It describes data that already + * exists, so every combination of replication and storage policy maps to some class. + * Replication decides the class, and only a COLD storage policy changes it.</li> + * </ul> + */ +public final class S3StorageClassResolver { + + /** EC layout used when neither the request nor the bucket specifies one. */ + private static final ECReplicationConfig DEFAULT_EC_REPLICATION_CONFIG = + new ECReplicationConfig(3, 2); + + private S3StorageClassResolver() { + } + + /** + * Forward mapping: the spec for a write that requests the given storage class. + * + * <p>For {@code STANDARD} and {@code REDUCED_REDUNDANCY}, the storage policy comes from the + * class's gateway setting. When the setting is empty, the spec has no storage policy and the + * write inherits the bucket's. + * + * @param s3StorageClass the {@code x-amz-storage-class} header value + * @param conf gateway configuration + * @throws IllegalArgumentException if the storage class is unknown, or its configured storage + * policy is not valid + */ + @Nonnull + public static S3StorageClassSpec toSpec(String s3StorageClass, ConfigurationSource conf) { + S3StorageClass storageClass = S3StorageClass.fromS3StorageClass(s3StorageClass); + S3StorageClassSpec spec = storageClass.getSpec(); + switch (storageClass) { + case STANDARD: + return spec.withStoragePolicy( + getConfiguredStoragePolicy(conf, OZONE_S3G_STORAGE_CLASS_STANDARD_STORAGE_POLICY)); + case REDUCED_REDUNDANCY: + return spec.withStoragePolicy(getConfiguredStoragePolicy(conf, + OZONE_S3G_STORAGE_CLASS_REDUCED_REDUNDANCY_STORAGE_POLICY)); + default: + return spec; + } + } + + /** + * The replication config for a write with the given spec. + * + * <p>For EC, the layout comes from the {@code storage-config} request header, then from the + * bucket's replication if it is EC, and otherwise defaults to EC 3-2. + * + * @param spec the spec from {@link #toSpec} + * @param storageConfigHeader the {@code storage-config} header value, or null + * @param bucketReplicationConfig the bucket's default replication, or null + * @throws IllegalArgumentException if the spec has no replication type, or + * {@code storageConfigHeader} is not a valid EC layout + */ + @Nonnull + public static ReplicationConfig toReplicationConfig(S3StorageClassSpec spec, + @Nullable String storageConfigHeader, @Nullable ReplicationConfig bucketReplicationConfig) { + ReplicationType type = spec.getReplicationType(); + if (type == ReplicationType.EC) { + if (StringUtils.isNotEmpty(storageConfigHeader)) { + return new ECReplicationConfig(storageConfigHeader); + } + if (bucketReplicationConfig instanceof ECReplicationConfig) { + return bucketReplicationConfig; + } + return DEFAULT_EC_REPLICATION_CONFIG; + } + if (type == ReplicationType.RATIS) { + return RatisReplicationConfig.getInstance(spec.getReplicationFactor()); + } + throw new IllegalArgumentException("Storage class spec has no supported replication type: " + + spec); + } + + /** + * Reverse mapping: the storage class to report for a stored key. + * + * <p>This never fails. Replication decides the class, and only a COLD storage policy changes it: + * <pre> + * COLD + RATIS -> GLACIER + * otherwise, by replication: + * EC -> STANDARD_IA + * STAND_ALONE, or a single replica -> REDUCED_REDUNDANCY + * anything else -> STANDARD + * </pre> + * A null storage policy, as on keys written before storage policy support, uses replication + * alone. A null replication reports {@code STANDARD}. + * + * @param replicationConfig the key's replication, or null + * @param storagePolicy the key's storage policy, or null + */ + @Nonnull + public static S3StorageClass toS3StorageClass(@Nullable ReplicationConfig replicationConfig, + @Nullable StoragePolicy storagePolicy) { + if (replicationConfig == null) { + return S3StorageClass.STANDARD; + } + if (storagePolicy == OzoneStoragePolicy.COLD + && replicationConfig.getReplicationType() == ReplicationType.RATIS) { + return S3StorageClass.GLACIER; + } Review Comment: @SaketaChalamchala I am little confused now, we agreed to have gateway configs for admin to define in forward write operations for STANDARD and REDUCED_REDUNDANCY classes and that will be intentional right ? so confused with your below statement: `"_gateway configs are also not reliable as they can change between restarts"_` I agree that we should have similar config for STANDARD_IA also. Consider this sequence once the S3 write integration is connected in follow up PRs: Step | Gateway setting for STANDARD | Operation | Stored object policy 1 | HOT | Upload a.txt | HOT 2 | Change to WARM and restart | No object write | a.txt remains HOT 3 | WARM | Upload b.txt | WARM Both objects can report the `STANDARD` storage class because both use `RATIS/THREE` The administrator’s change will be intentional and valid. But the current gateway configuration cannot tell us the policy of `a.txt` Current gateway configuration: WARM ``` a.txt’s stored policy: HOT b.txt’s stored policy: WARM ``` Therefore: - For a new write: use the applicable gateway configuration to select the policy. - For an existing object: inspect that object’s stored metadata. Changing a write setting does not itself change previously stored objects. My understanding is that we should retain the gateway settings for `STANDARD` and `REDUCED_REDUNDANCY` writes, and consider the same approach for `STANDARD_IA`. These settings are loaded at startup, so an intentional configuration change followed by restart affects subsequent writes. Existing objects retain their stored policies, and reverse mapping uses their stored metadata rather than the current gateway settings. Is your concern about using gateway configuration to interpret existing objects, or are you also proposing changes to the write settings? I have done the changes for gateway config for `STANDARD_IA` as well and removed hardcoded policy association with `STANDARD_IA`. Also I would suggest to use `DEEP_ARCHIVE` name instead of `GLACIER_DEEP_ARCHIVE`, but in terms they are both same in view of AWS specs. -- 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]
