[devmadhuu]

What changes were proposed in this pull request?

SCM counts pipelines per storage tier but calculates the pipeline ceiling using all healthy datanodes, including those that do not support the requested tier. This can allow unnecessary creation attempts that later fail placement checks.

Calculate the ceiling using healthy, in-service datanodes supporting the requested tier. Preserve existing per-datanode limits, placement checks and configuration defaults.

Configuration

ozone.scm.datanode.pipeline.limit — default: 2

For a positive value:

• Before storage policies: the value limits total RATIS/THREE pipeline
  participation on each datanode.
• With storage policies: the same value applies independently to each
  supported storage type on the datanode.
• Additional data volumes of the same type do not multiply the limit.

For example, with the default value of 2, a datanode supporting SSD and
DISK can participate in up to 2 SSD pipelines and 2 DISK pipelines.

When this configuration is 0, SCM derives the datanode limit from:

ozone.scm.pipeline.per.metadata.disk × reported Ratis metadata/log volume count

ozone.scm.pipeline.per.metadata.disk defaults to 2. These are Ratis
metadata/log volumes, not SSD/DISK data-volume counts. This calculation is
unchanged by this PR.

Before storage policies — master

The following examples use positive values of
ozone.scm.datanode.pipeline.limit.

Cluster layout	Pipeline limit with Config = 1	Pipeline limit with Config = 2	Pipeline limit with Config = 3
3 DNs, each with 1 data volume	1	2	3
3 DNs, each with 2 data volumes	1	2	3
3 DNs, each with 3 data volumes	1	2	3
3 DNs, each with 4 data volumes	1	2	3
6 DNs, each with 2 data volumes	2	4	6

Cluster pipeline ceiling:

floor(ozone.scm.datanode.pipeline.limit × healthy DN count ÷ 3)

After storage policies, including this PR

Cluster layout	Pipeline limit with Config = 1	Pipeline limit with Config = 2	Pipeline limit with Config = 3
3 DNs, each with 1 SSD volume	1 SSD	2 SSD	3 SSD
3 DNs, each with 2 SSD volumes	1 SSD	2 SSD	3 SSD
3 DNs, each with 1 DISK volume	1 DISK	2 DISK	3 DISK
3 DNs, each with 1 SSD + 1 DISK	1 SSD + 1 DISK = 2	2 SSD + 2 DISK = 4	3 SSD + 3 DISK = 6
3 DNs, each with 2 SSD + 1 DISK	1 SSD + 1 DISK = 2	2 SSD + 2 DISK = 4	3 SSD + 3 DISK = 6
3 DNs, each with 2 SSD + 2 DISK	1 SSD + 1 DISK = 2	2 SSD + 2 DISK = 4	3 SSD + 3 DISK = 6
6 DNs: 3 SSD-only + 3 DISK-only	1 SSD + 1 DISK = 2	2 SSD + 2 DISK = 4	3 SSD + 3 DISK = 6
6 DNs, each with 1 SSD + 1 DISK	2 SSD + 2 DISK = 4	4 SSD + 4 DISK = 8	6 SSD + 6 DISK = 12

Per-type cluster pipeline ceiling:

floor(ozone.scm.datanode.pipeline.limit × healthy DNs supporting that type ÷ 3)

All table values are cluster-wide ceilings for distinct RATIS/THREE pipelines.
Each pipeline requires three datanodes. Actual creation also depends on
per-datanode limits, capacity and placement checks.

Example: six mixed datanodes with the configuration set to 3

• SSD: 6 datanodes × 3 memberships ÷ 3 members per pipeline = 6 pipelines.
• DISK: 6 datanodes × 3 memberships ÷ 3 members per pipeline = 6 pipelines.
• Cluster total: up to 12 pipelines.
• Each datanode participates in up to 3 SSD and 3 DISK pipelines.

What this PR changes

Independent per-type datanode limits already exist in the storage-policy
feature branch. This PR corrects the cluster-wide ceiling calculation.

For example, consider 3 SSD-only datanodes and 3 DISK-only datanodes, with
ozone.scm.datanode.pipeline.limit = 2:

• Before this PR, the SSD ceiling calculation counted all 6 datanodes:
  6 × 2 ÷ 3 = 4.
• After this PR, it counts only the 3 SSD-capable datanodes:
  3 × 2 ÷ 3 = 2.

Existing per-datanode checks already restrict actual pipeline creation.
This change makes the cluster-wide ceiling consistent with those checks.
It introduces no configuration changes.

What is the link to the Apache JIRA?

HDDS-17723

How was this patch tested?

• Added coverage for dedicated and mixed storage types, duplicate volumes, missing/legacy reports, unhealthy nodes and limit boundaries.
• Existing tests passed across provider, placement, background creation, container allocation and pipeline-state suites.
• Verified the dedicated-tier regression test fails against the original implementation.
• Repository Checkstyle passed with zero violations.

[devmadhuu]

@anuragp010 Kindly have a look.

[devmadhuu]

@ashishkumar50 Please check PR description on pipeline limit with storage tiers. It makes sense to have separate pipeline limit to be applied per tier because writes will happen on each tier separately based on type of tier data.