Hi Brian,

Thanks for the KIP.

The KIP says:

 > As represented by the current ZK node structure, the order in which quotas 
 > are matched are as follows. Note <user> is a specified user principal, 
 > <client-id> is a specified client ID, and <default> is a special default 
 > user/client ID that matches to all users or clients IDs.

This is probably a nitpick, but it would be nice to specify that this list is 
in order of highest priority to lowest.

> --include-overrides: Whether to include overridden config entries.

Hmm.  Maybe --show-overridden or --include-overridden is a better flag name?

I think it would be nice to avoid using enums for QuotaEntity#Type, 
QuotaKey#Type, and QuotaFilter#Rule.  With enums, we have to worry about 
forwards and backwards compatibility problems.  For example, what do you do 
when you're querying a broker that has a new value for one of these, that is 
not in your enum?  In the  past, we've created an UNKNOWN value for enum types 
to solve this conundrum, but I'm not sure the extra complexity is worth it 
here.  We can jut make them strings and avoid worrying about the compatibility 
issues.

Is QuotaKey#Units really needed?  It seems like perhaps QuotaKey#Type could 
imply the units used.

>    public DescribeQuotasResult(KafkaFuture<Map<QuotaEntity, Map<QuotaKey, 
> Long>>> entities);

How common is the prefix matching use-case?  I haven't heard about people 
setting up principal names with a common prefix or anything like that-- is that 
commonly done?

I sort of feel like maybe we could have a simpler API for describeQuotas where 
it takes a map of quota entity type to value, and we do a logical AND On that.  
I'm not sure if there's really a reason why it needs to be a collection rather 
than a set, in other words...

cheers,
Colin


On Wed, Dec 11, 2019, at 15:30, Brian Byrne wrote:
> Hello all,
> 
> I'm reviving the discussion for adding a quotas API to the admin client by
> submitting a new proposal. There are some notable changes from previous
> attempts, namely a way to deduce the effective quota for a client (entity),
> a way to query for configured quotas, and the concept of "units" on quotas,
> among other minor updates.
> 
> Please take a look, and I'll be happy to make any clarifications and
> modifications in regards to feedback.
> 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-546%3A+Add+quota-specific+APIs+to+the+Admin+Client%2C+redux
> 
> Thanks,
> Brian
>

Reply via email to