HDDS-16018. Use configured DNS-to-switch mapping directly in SCM

[F64116045]

What changes were proposed in this pull request?

This change updates SCM to instantiate the configured DNSToSwitchMapping directly instead of wrapping every non-cached mapping in CachedDNSToSwitchMapping.

This follows up on the topology mapping behavior discussed in apache/ozone#10598, where static host-to-rack mappings should not be affected by an additional SCM-side cache wrapper.

The default mapping behavior remains cached because Hadoop ScriptBasedMapping already extends CachedDNSToSwitchMapping. Using configured mappings directly avoids changing their input through the cache wrapper hostname normalization step, which is important for mappings such as StaticMapping.

The patch also adds focused SCM coverage for the default cached mapping and direct configured mapping usage.

What is the link to the Apache JIRA

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

How was this patch tested?

mvn -B --no-transfer-progress -pl :hdds-server-scm -am -Dtest=TestStorageContainerManager,TestSCMBlockProtocolServer test -DskipShade -DskipRecon -DskipDocs
git diff --check

CI: https://github.com/F64116045/ozone/actions/runs/30590053420

[ivandika3]

cc: @hevinhsu

[hevinhsu]

Thanks @F64116045 for the patch! The change looks good to me. I also found that HDFS DatanodeManager instantiates the configured mapping directly.

I noticed a few details that I’d like to confirm with the maintainers:

1. Since HDDS-1663, SCM has automatically wrapped non-cached mappings with CachedDNSToSwitchMapping. After removing the wrapper, caching and input handling will become the responsibility of the configured implementation. I’m wondering if this could affect existing custom mappings that rely on the current behavior, for example, mappings that expect normalized IP addresses or repeated lookups to be cached. Is this compatibility change expected and acceptable?

2. I noticed that OM has similar wrapper logic in KeyManagerImpl. Should SCM and OM follow the same behavior here? If OM should also use the configured mapping directly, should we handle it in this PR or track it separately?

If this behavior change is accepted, I think we should also raise a follow-up issue to update the corresponding topology documentation in apache/ozone-site.

[F64116045]

Thanks @hevinhsu for adding the context!

Yes, I think this could affect custom DNSToSwitchMapping implementations that relied on SCM's wrapper for hostname normalization or caching. My understanding is that the proposed behavior is to respect each configured DNSToSwitchMapping implementation: if an implementation needs caching, it can either implement caching itself or use CachedDNSToSwitchMapping where its normalization behavior is also desired.

I agree this compatibility point should be confirmed by the maintainers.

For OM, if this behavior change is accepted, I’m happy to help with the OM side as well, either in this PR or as a follow-up.