Hi Unmesh, Very cool prototype!
Hi Colin, The KIP proposes a record called IsrChange which includes the partition, topic, isr, leader and leader epoch. During normal operation ISR changes do not result in leader changes. Similarly, leader changes do not necessarily involve ISR changes. The controller implementation that uses ZK modeled them together because 1. All of this information is stored in one znode. 2. ZK's optimistic lock requires that you specify the new value completely 3. The change to that znode was being performed by both the controller and the leader. None of these reasons are true in KIP-500. Have we considered having two different records? For example 1. IsrChange record which includes topic, partition, isr 2. LeaderChange record which includes topic, partition, leader and leader epoch. I suspect that making this change will also require changing the message AlterIsrRequest introduced in KIP-497: Add inter-broker API to alter ISR. Thanks -Jose
