The PR for this KIP is ready for review. JIRA is https://issues.apache.org/jira/browse/KAFKA-3492, PR is https://github.com/apache/kafka/pull/1753.
Thanks, Rajini On Tue, Aug 9, 2016 at 1:06 PM, Rajini Sivaram <rajinisiva...@googlemail.com > wrote: > Hi Tom, > > Have updated the KIP wiki. Will submit a PR later this week. > > Regards, > > Rajini > > On Tue, Aug 9, 2016 at 12:30 PM, Tom Crayford <tcrayf...@heroku.com> > wrote: > >> Seeing as voting passed on this, can somebody with access update the wiki? >> >> Is there code for this KIP in a PR somewhere that needs merging? >> >> Thanks >> Tom Crayford >> Heroku Kafka >> >> On Friday, 1 July 2016, Rajini Sivaram <rajinisiva...@googlemail.com> >> wrote: >> >> > Thank you, Jun. >> > >> > Hi all, >> > >> > Please let me know if you have any comments or suggestions on the >> updated >> > KIP. If there are no objections, I will initiate voting next week. >> > >> > Thank you... >> > >> > >> > On Thu, Jun 30, 2016 at 10:37 PM, Jun Rao <j...@confluent.io >> <javascript:;>> >> > wrote: >> > >> > > Rajini, >> > > >> > > The latest wiki looks good to me. Perhaps you want to ask other >> people to >> > > also take a look and then we can start the voting. >> > > >> > > Thanks, >> > > >> > > Jun >> > > >> > > On Tue, Jun 28, 2016 at 6:27 AM, Rajini Sivaram < >> > > rajinisiva...@googlemail.com <javascript:;>> wrote: >> > > >> > > > Jun, >> > > > >> > > > Thank you for the review. I have changed all default property >> configs >> > to >> > > be >> > > > stored with the node name <default>. So the defaults are >> > > > /config/clients/<default> for default client-id quota, >> > > > /config/users/<default> for default user quota and >> > > > /config/users/<default/clients/<default> for default <user, >> client-id> >> > > > quota. Hope that makes sense. >> > > > >> > > > On Mon, Jun 27, 2016 at 10:25 PM, Jun Rao <j...@confluent.io >> > <javascript:;>> wrote: >> > > > >> > > > > Rajini, >> > > > > >> > > > > Thanks for the update. Looks good to me. My only comment is that >> > > > > instead of /config/users/<default>/clients, >> > > > > would it be better to represent it as >> > > > > /config/users/<default>/clients/<default> >> > > > > so that it's more consistent? >> > > > > >> > > > > Jun >> > > > > >> > > > > >> > > > > On Thu, Jun 23, 2016 at 2:16 PM, Rajini Sivaram < >> > > > > rajinisiva...@googlemail.com <javascript:;>> wrote: >> > > > > >> > > > > > Jun, >> > > > > > >> > > > > > Yes, I agree that it makes sense to retain the existing >> semantics >> > for >> > > > > > client-id quotas for compatibility. Especially if we can provide >> > the >> > > > > option >> > > > > > to enable secure client-id quotas for multi-user clusters as >> well. >> > > > > > >> > > > > > I have updated the KIP - each of these levels can have defaults >> as >> > > well >> > > > > as >> > > > > > specific entries: >> > > > > > >> > > > > > - /config/clients : Insecure <client-id> quotas with the same >> > > > > semantics >> > > > > > as now >> > > > > > - /config/users: User quotas >> > > > > > - /config/users/userA/clients: <user, client-id> quotas for >> > userA >> > > > > > - /config/users/<default>/clients: Default <user, client-id> >> > > quotas >> > > > > > >> > > > > > Now it is fully flexible as well as compatible with the current >> > > > > > implementation. I used /config/users/<default>/clients rather >> than >> > > > > > /config/users/clients since "clients" is a valid (unlikely, but >> > still >> > > > > > possible) user principal. I used <default>, but it could be >> > anything >> > > > that >> > > > > > is a valid Zookeeper node name, but not a valid URL-encoded >> name. >> > > > > > >> > > > > > Thank you, >> > > > > > >> > > > > > Rajini >> > > > > > >> > > > > > On Thu, Jun 23, 2016 at 3:43 PM, Jun Rao <j...@confluent.io >> > <javascript:;>> wrote: >> > > > > > >> > > > > > > Hi, Rajini, >> > > > > > > >> > > > > > > For the following statements, would it be better to allocate >> the >> > > > quota >> > > > > to >> > > > > > > all connections whose client-id is clientX? This way, existing >> > > > > client-id >> > > > > > > quotas are fully compatible in the new release whether the >> > cluster >> > > is >> > > > > in >> > > > > > a >> > > > > > > single user or multi-user environment. >> > > > > > > >> > > > > > > 4. If client-id quota override is defined for clientX in >> > > > > > > /config/clients/clientX, this quota is allocated for the sole >> use >> > > of >> > > > > > > <userN, >> > > > > > > clientX> >> > > > > > > 5. If dynamic client-id default is configured in >> /config/clients, >> > > > this >> > > > > > > default quota is allocated for the sole use of <userN, >> clientX> >> > > > > > > 6. If quota.producer.default is configured for the broker in >> > > > > > > server.properties, this default quota is allocated for the >> sole >> > use >> > > > of >> > > > > > > <userN, >> > > > > > > clientX> >> > > > > > > >> > > > > > > We can potentially add a default quota for both user and >> client >> > at >> > > > path >> > > > > > > /config/users/clients? >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Jun >> > > > > > > >> > > > > > > On Wed, Jun 22, 2016 at 3:01 AM, Rajini Sivaram < >> > > > > > > rajinisiva...@googlemail.com <javascript:;>> wrote: >> > > > > > > >> > > > > > > > Ismael, Jun, >> > > > > > > > >> > > > > > > > Thank you both for the feedback. Have updated the KIP to add >> > > > dynamic >> > > > > > > > default quotas for client-id with deprecation of existing >> > static >> > > > > > default >> > > > > > > > properties. >> > > > > > > > >> > > > > > > > >> > > > > > > > On Wed, Jun 22, 2016 at 12:50 AM, Jun Rao <j...@confluent.io >> > <javascript:;>> >> > > > wrote: >> > > > > > > > >> > > > > > > > > Yes, for consistency, perhaps we can allow client-id >> quota to >> > > be >> > > > > > > > configured >> > > > > > > > > dynamically too and mark the static config in the broker >> as >> > > > > > deprecated. >> > > > > > > > If >> > > > > > > > > both are set, the dynamic one wins. >> > > > > > > > > >> > > > > > > > > Thanks, >> > > > > > > > > >> > > > > > > > > Jun >> > > > > > > > > >> > > > > > > > > On Tue, Jun 21, 2016 at 3:56 AM, Ismael Juma < >> > > ism...@juma.me.uk <javascript:;>> >> > > > > > > wrote: >> > > > > > > > > >> > > > > > > > > > On Tue, Jun 21, 2016 at 12:50 PM, Rajini Sivaram < >> > > > > > > > > > rajinisiva...@googlemail.com <javascript:;>> wrote: >> > > > > > > > > > >> > > > > > > > > > > It is actually quite tempting to do the same for >> > client-id >> > > > > quotas >> > > > > > > as >> > > > > > > > > > well, >> > > > > > > > > > > but I suppose we can't break existing users who have >> > > > configured >> > > > > > > > > defaults >> > > > > > > > > > in >> > > > > > > > > > > server.properties and providing two ways of setting >> > > client-id >> > > > > > > > defaults >> > > > > > > > > > > would be just too confusing. >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Using two different approaches for client-id versus user >> > > quota >> > > > > > > defaults >> > > > > > > > > is >> > > > > > > > > > also not great. We could deprecate the server.properties >> > > > default >> > > > > > > > configs >> > > > > > > > > > for client-id quotas and remove them in the future. In >> the >> > > > > > meantime, >> > > > > > > we >> > > > > > > > > > would have to live with 2 level defaults. >> > > > > > > > > > >> > > > > > > > > > Jun, what are your thoughts on this? >> > > > > > > > > > >> > > > > > > > > > Ismael >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Regards, >> > > > > > > > >> > > > > > > > Rajini >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > -- >> > > > > > Regards, >> > > > > > >> > > > > > Rajini >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Regards, >> > > > >> > > > Rajini >> > > > >> > > >> > >> > >> > >> > -- >> > Regards, >> > >> > Rajini >> > >> > > > > -- > Regards, > > Rajini > -- Regards, Rajini
