Hi Jose, That'a s good point that I hadn't considered. It's probably worth having a separate leader change message, as you mentioned.
Hi Unmesh, Thanks, I'll take a look. best, Colin On Fri, Aug 7, 2020, at 11:56, Jose Garcia Sancio wrote: > 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 >
