>>Hi Unmesh, >>Thanks, I'll take a look. Thanks. I will be adding more to the prototype and will be happy to help and collaborate.
Thanks, Unmesh On Tue, Aug 11, 2020 at 12:28 AM Colin McCabe <cmcc...@apache.org> wrote: > 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 > > >
