Ewen, Thank you for the review. I agree that ideally we would have one definition of quotas that handles all cases. But I couldn't quite fit all the combinations that are possible today with client-id-based quotas into the new configuration. I think upgrade path is not bad since quotas are per-broker. You can configure quotas based on the new configuration, set quota.secure.enable=true and restart the broker. Since there is no requirement for both insecure client-id based quotas and secure user-based quotas to co-exist in a cluster, isn't that sufficient? The implementation does use a unified approach, so if an alternative configuration can be defined (perhaps with some acceptable limitations?) which can express both, it will be easy to implement. Suggestions welcome :-)
The cases that the new configuration cannot express, but the old one can are: 1. SSL/SASL with multiple users, same client ids used by multiple users, client-id based quotas where quotas are shared between multiple users 2. Default quotas for client-ids. In the new configuration, default quotas are defined for users and clients with no configured sub-quota share the user's quota. On Sat, Apr 30, 2016 at 6:21 AM, Ewen Cheslack-Postava <e...@confluent.io> wrote: > Rajini, > > I'm admittedly not very familiar with a lot of this code or implementation, > so correct me if I'm making any incorrect assumptions. > > I've only scanned the KIP, but my main concern is the rejection of the > alternative -- unifying client-id and principal quotas. In particular, > doesn't this make an upgrade for brokers using those different approaches > difficult since you have to make a hard break between client-id and > principal quotas? If people adopt client-id quotas to begin with, it seems > like we might not be providing a clean upgrade path. > > As I said, I haven't kept up to date with the details of the security and > quota features, but I'd want to make sure we didn't suggest one path with > 0.9, then add another that we can't provide a clean upgrade path to. > > -Ewen > > On Fri, Apr 22, 2016 at 7:22 AM, Rajini Sivaram < > rajinisiva...@googlemail.com> wrote: > > > The PR for KAFKA-3492 (https://github.com/apache/kafka/pull/1256) > contains > > the code associated with KIP-55. I will keep it updated during the review > > process. > > > > Thanks, > > > > Rajini > > > > On Mon, Apr 18, 2016 at 4:41 PM, Rajini Sivaram < > > rajinisiva...@googlemail.com> wrote: > > > > > Hi All, > > > > > > I have just created KIP-55 to support quotas based on authenticated > user > > > principals. > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-55%3A+Secure+Quotas+for+Authenticated+Users > > > > > > Comments and feedback are appreciated. > > > > > > Thank you... > > > > > > Regards, > > > > > > Rajini > > > > > > > > > > > -- > > Regards, > > > > Rajini > > > > > > -- > Thanks, > Ewen > -- Regards, Rajini
