Hi Fahid, Thanks for this KIP. We have ideated internally around a similar need, and I think this addresses a real problem.
I wonder if there is a gap in the KIP as proposed for a scenario where an operator would not immediately reassign all partitions to a replacement broker at once. If this happens in batches that are completed before making new moves, would using the wait-for-sync mode mean that leaderships move to the new broker once the first batch completes? Would there be a way to control that, such that leadership can be held back from the new broker until all intended reassignments have been made? I think this is quite similar to the broker cordoning feature, but limited to leadership and used at the start of a brokers lifecycle rather than at the end. But there may be reason to look toward how that's designed, and have symmetry with the way that is configurable. BR, Anton Den tis 28 juli 2026 kl 11:45 skrev Fahid Abdullah <[email protected]>: > Hello, I was hoping we could start the review and voting process for > KIP-1358. > > On 2026/06/16 18:19:54 Haifeng Chen wrote: > > start a discussion thread for > > > > KIP-1358: Gradual and gated preferred-leader election in the KRaft > controller > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1358%3A+Gradual+and+gated+preferred-leader+election+in+the+KRaft+controller > >
