Hello chia, peng, I completely agree that Apache Kafka places a strong emphasis on compatibility. I believe the ReplicaPlacer plugin is primarily intended for advanced users—most common users are unlikely to implement their own plugin. Therefore, using an UNSTABLE or internal configuration is a trade-off we need to consider.
If we make this configuration public and mark its interface as UNSTABLE, the advantage is that more users will be able to use it if they are comfortable with the API’s instability. The downside is that this would be the first UNSTABLE API exposed directly to users. Alternatively, if we make the configuration internal, the advantage is that we are not required to maintain compatibility since it is not exposed to users. However, the downside is that most users would not be aware of the configuration at all. On balance, I think making this configuration public (while clearly marking it as UNSTABLE) will provide more opportunities to gather feedback from users and improve the interface over time. Therefore, I will update this KIP to make the configuration public and mark it as UNSTABLE. Best Regards, Jiunn-Yang > peng <p1070048...@gmail.com> 於 2025年8月20日 下午4:13 寫道： > > +1 > best regards > > Chia-Ping Tsai <chia7...@apache.org> 于 2025年8月20日周三 下午3:46写道： > >> I really like the idea of offering more flexible and powerful assignment >> policies. However, maintaining such implementations could become an >> overhead for the community. This is especially important because Apache >> Kafka places a strong emphasis on compatibility. >> >> The value of this KIP lies in opening the door for advanced developers to >> deploy custom assignments without modifying the source code. >> >> With respect to this KIP, perhaps we could expose a public configuration >> backed by UNSTABLE APIs. This approach would give us the flexibility to >> adjust the APIs in minor releases >> >> Best, >> Chia-Ping >> >> On 2025/08/18 02:21:15 peng wrote: >>> I think making `ReplicaPlacer` configurable is a good strategy. We can >>> integrate KIP-1194: Optimize Replica Assignment for Broker Load Balance >> in >>> Uneven Rack Configurations into it, allowing users to choose between the >>> current `StripedReplicaPlacer` approach or the `WeightedReplicaPlacer` >>> mentioned in KIP-1194. >>> >>> Perhaps the replica reassignment algorithm could also be made >> configurable, >>> enabling users to select solutions like KIP-1151: Minimal movement >> replica >>> balancing algorithm through configuration. >>> >>> 黃竣陽 <s7133...@gmail.com> 于 2025年8月6日周三 下午8:03写道： >>> >>>> Hello chia, >>>> >>>> Thanks for the reply, >>>> >>>> chia_00, chia_01, chia_02: I have updated the KIP based on your >> comments. >>>> >>>> Best Regards, >>>> Jiunn-Yang >>>> >>>>> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年8月6日 凌晨12:18 寫道： >>>>> >>>>> hi Jiunn-Yang >>>>> >>>>> chia_00: >>>>> >>>>> Could you please add more alternatives? For example, users could use >> the >>>>> admin to reassign partitions after the topics are created, or >> specify the >>>>> assignments directly when creating the topics >>>>> >>>>> chia_01: >>>>> >>>>> should we consider making `ReplicaPlacer` configurable? >>>>> >>>>> chia_02: >>>>> >>>>> Could you please enrice the documentation to remind users that this >>>>> configuration is internal, and clarify the specific use cases where >> it >>>>> might be relevant? >>>>> >>>>> Best, >>>>> Chia-Ping >>>>> >>>>> 黃竣陽 <s7133...@gmail.com> 於 2025年8月5日 週二 下午11:24寫道： >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I would like to start a discussion on KIP-1203: Allow to configure >>>> custom >>>>>> `ReplicaPlacer` implementation >>>>>> <https://cwiki.apache.org/confluence/x/dxFJFg> >>>>>> >>>>>> This proposal introduces a new internal configuration, >>>>>> replica.placer.class.name, which >>>>>> allows users to specify a custom implementation of ReplicaPlacer. >>>>>> >>>>>> Best regards, >>>>>> Jiunn-Yang >>>> >>>> >>> >>
