HDDS-15408. SCM ContainerInfo Support Create And Get With StorageTier

[devmadhuu]

What changes were proposed in this pull request?

Persist the storage tier on ContainerInfo so SCM restart preserves each container's intended tier. Follow-up to #10573 (which put the tier on Pipeline)

Please describe your PR in detail:
Replication Manager, Container Balancer, Decommissioning needs to know a container's intended tier without inferring it from replica reports. Today it's lost across SCM restart.

What is the link to the Apache JIRA

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

How was this patch tested?

Added tests in TestSCMRestart to assert the tier survives SCM restart and that newly-allocated containers after restart still inherit the pipeline's tier.

[xichen01]

@devmadhuu Thank you very much for your commit

Apologies for the delayed response in ticket https://issues.apache.org/jira/browse/HDDS-15408.

Regarding the StoragePolicy feature branch, would it be possible to create a ticket and implement the feature based on the commits in the following branch?

https://github.com/ivandika3/ozone/tree/refs/heads/backport-storage-policy-storage-class
or
https://issues.apache.org/jira/secure/attachment/13077025/storage-policy-diff.tar.gz

Previous discussions can be found here: #6989

This feature has already been fully implemented in our internal branch and has been running in production for some time. The branch linked above is a rough version created by cherry-picking the relevant commits from our internal implementation.

Using it as a reference would allow us to reuse more of the existing implementation and significantly reduce the development effort.

If you have other suggestions or prefer a different approach, we would be happy to discuss them.

[devmadhuu]

@devmadhuu Thank you very much for your commit

Apologies for the delayed response in ticket https://issues.apache.org/jira/browse/HDDS-15408.

Regarding the StoragePolicy feature branch, would it be possible to create a ticket and implement the feature based on the commits in the following branch?

https://github.com/ivandika3/ozone/tree/refs/heads/backport-storage-policy-storage-class or https://issues.apache.org/jira/secure/attachment/13077025/storage-policy-diff.tar.gz

Previous discussions can be found here: #6989

This feature has already been fully implemented in our internal branch and has been running in production for some time. The branch linked above is a rough version created by cherry-picking the relevant commits from our internal implementation.

Using it as a reference would allow us to reuse more of the existing implementation and significantly reduce the development effort.

If you have other suggestions or prefer a different approach, we would be happy to discuss them.

Thanks @xichen01 for your suggestions, but for community development, we usually follow the feature branch approach where Feature branch HDDS-11233 seems appropriate for further developments post this last PR in this branch. So if this feature has already been fully implemented in your branch, could you kindly raise follow up PRs in Feature branch HDDS-11233, so that any remaining impacts and other pending items can be picked up after we test impact on other features before the feature finally lands up on master.

cc: @jojochuang

[xichen01]

Thanks @xichen01 for your suggestions, but for community development, we usually follow the feature branch approach where Feature branch HDDS-11233 seems appropriate for further developments post this last PR in this branch. So if this feature has already been fully implemented in your branch, could you kindly raise follow up PRs in Feature branch HDDS-11233, so that any remaining impacts and other pending items can be picked up after we test impact on other features before the feature finally lands up on master.

Thanks @devmadhuu for the clarification.

The HDDS-11233 previous PRs were already created by cherry-picking our internal commits in the same order and adapting them to the community branch.

Our concern is that the current implementation for this ticket differs from our internal version. This would make the following commits (cherry-pick) difficult to reuse through cherry-picking and require substantial rework, even though the final result may be similar.

Would it be possible to align this implementation more closely with the branch we shared, while still submitting the PR to HDDS-11233?