HDDS-15242. Container report support StorageType

[xichen01]

What changes were proposed in this pull request?

Support for Datanode to report the StorageType of container replicas to SCM

• Subsequently, SCM will determine whether the container replica needs to be migrated based on the ContainerReplicaStorageType, and verify whether the storage policy for the key is satisfied.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15242

How was this patch tested?

New tests.

[xichen01]

@greenwich @chungen0126 @ivandika3 @peterxcli Please help to review

[greenwich]

Thanks! LGTM with one note though:

It's not directly related to this PR: StorageTypeUtils.getStorageTypeProto throws an unchecked IllegalArgumentException for any org.apache.hadoop.fs.StorageType it doesn't map. With Hadoop 3.4.3 that enum includes NVDIMM, which StorageTypeProto doesn't cover, and StorageLocation.parse accepts an [NVDIMM]/... entry in hdds.datanode.dir with no Ozone-side filtering. So a datanode with such a volume would throw here on every buildContainerReplicaProto, breaking that DN's container report.

[xichen01]

Thanks! LGTM with one note though:

It's not directly related to this PR: StorageTypeUtils.getStorageTypeProto throws an unchecked IllegalArgumentException for any org.apache.hadoop.fs.StorageType it doesn't map. With Hadoop 3.4.3 that enum includes NVDIMM, which StorageTypeProto doesn't cover, and StorageLocation.parse accepts an [NVDIMM]/... entry in hdds.datanode.dir with no Ozone-side filtering. So a datanode with such a volume would throw here on every buildContainerReplicaProto, breaking that DN's container report.

@greenwich

Thank you for your feedback. This is a vulnerability that needs to be fixed.

I'm considering whether to use Hadoop's org.apache.hadoop.fs.StorageType in Ozone. Perhaps we should define a custom org.apache.ozone.fs.StorageType.
Currently, using org.apache.hadoop.fs.StorageType doesn't seem to offer any benefits. Hadoop's org.apache.hadoop.fs.FileSystem only uses StorageType in setQuotaByStorageType, and Ozone may not be compatible with this interface.
If we define a custom StorageType, we can set the enum content more flexibly.

---

By the way, have you guys tried using the Storage Policy feature internally yet?

[greenwich]

@greenwich

Thank you for your feedback. This is a vulnerability that needs to be fixed.

I'm considering whether to use Hadoop's org.apache.hadoop.fs.StorageType in Ozone. Perhaps we should define a custom org.apache.ozone.fs.StorageType. Currently, using org.apache.hadoop.fs.StorageType doesn't seem to offer any benefits. Hadoop's org.apache.hadoop.fs.FileSystem only uses StorageType in setQuotaByStorageType, and Ozone may not be compatible with this interface. If we define a custom StorageType, we can set the enum content more flexibly.

I agree, having org.apache.ozone.fs.StorageType is a much better choice.

[greenwich]

By the way, have you guys tried using the Storage Policy feature internally yet?

On trying it internally: not end-to-end yet. The merged work plus this PR gives a solid datanode foundation (select/persist/create container by StorageType) and SCM replica-tier visibility, but the write path that would use it isn't wired on HDDS-11233 yet — OM doesn't read a bucket/key policy at allocation, the block location carries no storage type, and SCM allocation/pipelines aren't tier-aware. So two buckets tagged for different tiers still land on the same hardware today.

We're excited about the feature and are following closely. Once the placement path is finalised, we'd be happy to validate it on a mixed SSD/HDD cluster or provide any other help if needed. Is that roughly the next milestone you're targeting?