raghavyadav01 opened a new pull request, #19860:
URL: https://github.com/apache/pinot/pull/19860
A tier whose instance partitions have been assigned and persisted gets them
honoured by the rebalancer: `TableRebalancer.getInstancePartitionsForTier`
fetches `<rawTable>__TIER__<tier>` and lays the table's segments out against
it. Segment assignment does not. `TierConfigUtils.getTieredInstancePartitions`
always calls `computeDefaultInstancePartitionsForTag`, so the record is written
and then ignored.
The asymmetry is visible in the one caller,
`PinotHelixResourceManager.getInstancePartitionsMap`:
```java
if (tierName != null) {
...
TierConfigUtils.getTieredInstancePartitions(tableConfig, tier,
_helixZkManager); // compute, always
} else {
return fetchOrComputeInstancePartitions(tableConfig.getTableName(),
tableConfig); // fetch, then compute
}
```
So for a table whose `instanceAssignmentConfigMap` configures a tier, the
layout survives only until the next segment is added. The rebalance places
existing segments per the record; every segment added afterwards is placed by a
default computed over the tier's tagged instances, against a record that says
otherwise. The layout drifts further from the assignment with each segment
added, and nothing surfaces the divergence — the record still reads as
configured, and the segments are online.
The effect is worst for a replica-group assignment, where the default
collapses the configured partitions into a single partition over all tagged
instances: a 2-partition assignment comes back as `numPartitions == 1`, so
partition-aware placement is lost for everything added after the rebalance.
Fetch the tier's instance partitions first, fall back to the default only
when the tier has none — the same fetch-then-compute order the non-tiered
branch already uses. Behaviour is unchanged for any tier without a persisted
record, which is every tier that has no `instanceAssignmentConfigMap` entry,
since that is the only thing that creates one.
### Testing
`TierConfigUtilsTest.testGetTieredInstancePartitionsUsesPersistedAssignment`
reproduces it: a persisted 2-partition, 2-replica-group tier assignment comes
back as 1 partition over all tagged instances before the fix (`expected [2] but
found [1]`), and as the assignment after it. It covers both
`getTieredInstancePartitions` and the per-segment
`getTieredInstancePartitionsForSegment` entry point that segment assignment
goes through. `testGetTieredInstancePartitionsFallsBackToDefault` pins the
no-record path.
73 tests in `controller.helix.core.assignment` pass unchanged, including the
tiered assignment and `TableRebalancer` suites.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
