Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
MIME-Version: 1.0
In-Reply-To: <CAFc58G9nxq30huFAmxiHEer_sLReBe7Rfs2--38S0RZpLnYaxA@mail.gmail.com>
References: <CAOJcB396HYZ0E-C94KQMihwL7wpBXmErx4z_8KnhekfFbhpcPw@mail.gmail.com>
 <CAFc58G8YakghAj+vs0S08WnJhMA2jUsKjLeZRaZpy0RyD-=MZg@mail.gmail.com>
 <CAOJcB3_EAPs-51XJ2avDMX68O0Ri0dr9N9uFkRtNnbVmqwATHQ@mail.gmail.com>
 <CAOJcB3-CC0+vC=n+zhpGDGwffxZQVzeEbFAf-BG5bh=6jjDGww@mail.gmail.com>
 <1466008222.3923934.638665201.273F7E46@webmail.messagingengine.com>
 <CAOJcB38GyKMfVZrTVo7gHjP1gyCbxjeL+k2x6FbkwYZktwqpSg@mail.gmail.com>
 <CAFc58G-v5NvGLpMyre9tvovvFDOmDKPDSvKRtFHsrFUF56-P8A@mail.gmail.com>
 <CAOJcB3-L945rQJyf=GaPNoxrQEgxZC6A98o4bc5Bioa_5-ugAw@mail.gmail.com>
 <CAOJcB3_o-1v+V=hHrjxDJw=mkNBa3Xz1ed1tNApnFG5XXH-Y2Q@mail.gmail.com>
 <CAFc58G_4Z=cFEvJy6cpW-OuDZJO+Qtaff-LXPW1aL=GPsdG4ew@mail.gmail.com>
 <CAOJcB3937Jkv8dnuy6BsTLjjjhbxwQ3NoKZOqMJ0nQ1mi9k=Hg@mail.gmail.com>
 <CAFc58G8dv=QGsMswMrFmF4ZiWpPcB6oUB0N68YVC=5DiaB038g@mail.gmail.com>
 <CAOJcB3_6ZgsO4HrF6xivw-VMdqO7EHLj2hkOYLuU=8chQr-edw@mail.gmail.com>
 <CAOJcB3_=5X9+Vqwj_wBXM4t=ure5LZR+evFCa+h=-AFo0uwdRw@mail.gmail.com>
 <CAFc58G9EUhXqFGGOiiKV10wnsZVFEH0PhbW_Y1gz7eUSAQWUfQ@mail.gmail.com>
 <CAOJcB388FQ-t8GFETZN6axEC9XO=R9CkGKrqPj4rCXq65kB87A@mail.gmail.com>
 <CAD5tkZZA987xcG3gm1=MPPQDnzphyHCzXqWymq3DdwfHwQ9o3Q@mail.gmail.com>
 <CAFc58G_rceoGm6LvfFMoONisxTE3WHePBoTC2vOHRcjwHA4aEQ@mail.gmail.com>
 <CAOJcB38FvtL-xKQHFyHmbmhD=JRo1pGrtiQ-QfWwrGth5DNoMA@mail.gmail.com>
 <CAFc58G8XuZSyAX-veLaGx_V9iJ2GH3TjYvdrd7awNGKUnjpFpA@mail.gmail.com>
 <CAOJcB38BVQ0opeyuG7GEsAr-+pUy3oeBKQuD=fGMc3cPv4hevA@mail.gmail.com>
 <CAFc58G8TUicrfr=KhNSboZO81UuVGbVjWc7x_5v9Hhe0XxdCOg@mail.gmail.com>
 <CAOJcB3_rUq_VWh+mJpbjupkc95nqCUi4ZCP0ku7GCo1_FJ=ZGA@mail.gmail.com> <CAFc58G9nxq30huFAmxiHEer_sLReBe7Rfs2--38S0RZpLnYaxA@mail.gmail.com>
From: Rajini Sivaram <rajinisivaram@googlemail.com>
Date: Fri, 1 Jul 2016 09:31:58 +0100
Message-ID: <CAOJcB3-MzUtOHVeKUvciGEs=VTtMBxmdNGHMFxMiXhBWE88Ekw@mail.gmail.com>
Subject: Re: [VOTE] KIP-55: Secure quotas for authenticated users
To: dev@kafka.apache.org
Content-Type: multipart/alternative; boundary=001a11422e16f09a4405368ed119
archived-at: Fri, 01 Jul 2016 08:32:12 -0000

--001a11422e16f09a4405368ed119
Content-Type: text/plain; charset=UTF-8

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 <jun@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 <
> rajinisivaram@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 <jun@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 <
> > > rajinisivaram@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 <jun@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 <
> > > > > rajinisivaram@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 <jun@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 <
> ismael@juma.me.uk>
> > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, Jun 21, 2016 at 12:50 PM, Rajini Sivaram <
> > > > > > > > rajinisivaram@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

--001a11422e16f09a4405368ed119--