Hi, Mani, Thanks for the responses. A few more comments.
101.2/101.3. Could we just remove owner and renewer from DelegationTokenResponse if we don't have a use case? 111. ExpireTokenResponse: Should we return the new expiration time in the response? 112. DescribeTokenRequest: A common use case is probably to see a list of tokens associated with a particular owner. Would it be useful to include a list of owners in the request? We can use the same convention in other requests such that if the list is set to null (i.e., length is -1), return all tokens. 113. delegation.token.master.key: It seems that needs to be the same across brokers? Perhaps we can mention that in the wiki. 114. Could we document the procedure of manually rotating the secret? Does one have to do sth like: expire all existing tokens, rotate the secret, and generate new tokens? 115. Could we also include in the command line the ability to describe tokens? 116. Could you document the ACL rules associated with those new requests? For example, do we allow any one to create, delete, describe delegation tokens? Thanks, Jun On Wed, Feb 8, 2017 at 1:35 AM, Manikumar <manikumar.re...@gmail.com> wrote: > Hi Jun, > > > > 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. > > > > > Agree, we can run the token expiry check thread as part of controller > broker. > WIll update the KIP. > > > Thanks, > Manikumar > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
