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> 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> 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> 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> 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> 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> 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> > > 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> > > > > > wrote: > > > > > > > > > > > > > > > On Tue, Jun 21, 2016 at 12:50 PM, Rajini Sivaram < > > > > > > > > rajinisiva...@googlemail.com> 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
