Hi Viktor, Thanks for reviewing the KIP.
1. Yes, that is correct. Typically quotas would depend only on the current partition state. But if you did want to track deleted partitions, you can calculate the diff. 2. I can't think of an use case where ISRs or other replica information would be useful to configure quotas. Since partition leaders process fetch/produce requests, this is clearly useful in terms of setting quotas. But I have defined PartitionMetadata trait rather than just using the leader as an int so that we can add additional methods in future if required. This keeps the interface extensible. Did you have any use case in mind where additional metadata would be useful? Regards, Rajini On Tue, Mar 6, 2018 at 8:56 AM, Viktor Somogyi <viktorsomo...@gmail.com> wrote: > Hi Rajini, > > I've read through your KIP and it looks good, I only have two things to > clarify. > 1. How do we detect removed partitions in updatePartitionMetadata? I'm > presuming that the list here is the currently existing map of partitions, > so if something is removed it can be calculated as the diff of the current > and the previous update. Is that right? > 2. PartitionMetadata contains only the leader at this moment, however there > are similar classes that contain more information, like the replicas, isr, > offline replicas. I think including them might make sense to provide a more > robust API. What do you think? > > Thanks, > Viktor > > On Wed, Feb 21, 2018 at 7:57 PM, Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > > > Hi all, > > > > I have submitted KIP-257 to enable customisation of client quota > > computation: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > 257+-+Configurable+Quota+Management > > > > > > The KIP proposes to make quota management pluggable to enable group-based > > and partition-based quotas for clients. > > > > Feedback and suggestions are welcome. > > > > Thank you... > > > > Regards, > > > > Rajini > > >
