Update resource-propagating.md

[LavredisG]

/kind documentation

[LavredisG]

/kind documentation

1. Not totally sure about this PR because I can't quite understand the difference between ReplicaDivisionPreference.Aggregated and ReplicaDivisionPreference.Weighted.WeightPreference.DynamicWeight. Are they both based on cluster resource modeling (in that case why are there 2 same ways to divide replicas) or the second relies on the number of replicas already on the cluster (details on number 2)?

2. From the example we read that "It means replicas will be propagated based on available replicas in member clusters . For example, the scheduler selected 3 clusters (A/B/C) and should divide 12 replicas to them. Based on cluster resource modeling , we get that the max available replicas of A, B, C is 6, 12, 18. Therefore, the weight of cluster A:B:C will be 6:12:18 (equal to 1:2:3). At last, the assignment would be "A: 2, B: 4, C: 6"." when the case is DynamicWeight, which actually states 2 ways that the propagation happens. Either based on available replicas (replicas already existing on the clusters) or based on cluster resosurce modeling (how many replicas can fit in the cluster). I inferred that the correct case was the one based on the cluster resource modeling so I rephrased the paragraph for this case.

[RainbowMango]

Not totally sure about this PR because I can't quite understand the difference between ReplicaDivisionPreference.Aggregated and ReplicaDivisionPreference.Weighted.WeightPreference.DynamicWeight. Are they both based on cluster resource modeling (in that case why are there 2 same ways to divide replicas) or the second relies on the number of replicas already on the cluster (details on number 2)?

As described in the doc, the Aggregated means placing replicas in as few clusters as possible. Use cases include big data processing tasks where they prefer to run as much as possible within a single cluster to improve overall performance, but they can also tolerate replicas being distributed across multiple clusters.

The DynamicWeight applies to scenarios where administrators want to balance resource utilization across each cluster to avoid situations where some cluster are overloaded while others are underutilized.

[RainbowMango]

when the case is DynamicWeight, which actually states 2 ways that the propagation happens. Either based on available replicas (replicas already existing on the clusters) or based on cluster resosurce modeling (how many replicas can fit in the cluster). I inferred that the correct case was the one based on the cluster resource modeling so I rephrased the paragraph for this case.

Yeah, thank you. You are right.

[RainbowMango]

/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• docs/OWNERS [RainbowMango]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[LavredisG]

Not totally sure about this PR because I can't quite understand the difference between ReplicaDivisionPreference.Aggregated and ReplicaDivisionPreference.Weighted.WeightPreference.DynamicWeight. Are they both based on cluster resource modeling (in that case why are there 2 same ways to divide replicas) or the second relies on the number of replicas already on the cluster (details on number 2)?

As described in the doc, the Aggregated means placing replicas in as few clusters as possible. Use cases include big data processing tasks where they prefer to run as much as possible within a single cluster to improve overall performance, but they can also tolerate replicas being distributed across multiple clusters.

The DynamicWeight applies to scenarios where administrators want to balance resource utilization across each cluster to avoid situations where some cluster are overloaded while others are underutilized.

I see, thank you!