Read the KIP again and I think it looks good. +1 from me.
On Tue, Feb 7, 2017 at 3:05 PM, Jun Rao <j...@confluent.io> wrote: > Hi, Mani, > > If a token expires, then every broker will potentially try to delete it > around the same time, but only one will succeed. So, we will have to deal > with failures in that case? Another way is to let just one broker (say, the > controller) deletes expired tokens. > > It would also be helpful for others to give feedback on this KIP. Rajini, > Gwen, Ismael? > > Thanks, > > Jun > > > On Sun, Feb 5, 2017 at 9:54 AM, Manikumar <manikumar.re...@gmail.com> wrote: > >> Hi Jun, >> >> Please see the replies inline. >> >> >> > > >> > > Only one broker does the deletion. Broker updates the expiration in its >> > > local cache >> > > and on zookeeper so other brokers also get notified and their cache >> > > statuses are updated as well. >> > > >> > > >> > Which broker does the deletion? >> > >> >> Any broker can handle the create/expire/renew/describe delegationtoken >> requests. >> changes are propagated through zk notifications. Every broker is >> responsible for >> expiring the tokens. This check be can done during request handling time >> and/or >> during token authentication time. >> >> >> > >> > >> > 110. The diagrams in the wiki still show MD5 digest. Could you change it >> to >> > SCRAM? >> > >> > >> Updated the diagram. >> >> >> >> Thanks, >> Manikumar >> >> >> >> >> > >> > >> > > >> > > Thanks. >> > > Manikumar >> > > >> > > >> > > > >> > > > On Fri, Dec 23, 2016 at 9:26 AM, Manikumar < >> manikumar.re...@gmail.com> >> > > > wrote: >> > > > >> > > > > Hi, >> > > > > >> > > > > I would like to initiate the vote on KIP-48: >> > > > > >> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+ >> > > > > Delegation+token+support+for+Kafka >> > > > > >> > > > > >> > > > > Thanks, >> > > > > Manikumar >> > > > > >> > > > >> > > >> > >> -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
