Hi Boyang, Thanks for the KIP. The KIP looks good. I have a few questions and comments.
> As part of the KIP-500 <https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum> initiative, we need to build a bridge release version of Kafka that could isolate the direct Zookeeper write access only to the controller. This may be outside the scope of this KIP but I am trying to understand how this is going to be used to implement KIP-500. My understanding is that the Admin client discovers the controller by performing a Metadata{Request,Response} round trip. The response of this request includes the id of the controller. Based on my understanding of the KIP-500, this architecture will need to change. For example the controller will not necessarily be a broker in which case the id may not correlate to a broker id. Is the expectation that the Kafka Controller Quorum (as defined in KIP-500) will push this new connection information to all of the brokers? Will the Kafka Controller Quorum expose and implement all of the RPCs being redirected in this KIP and the ones that are currently routed to the controller? These include: ListPartitionReassignment AlterPartitionReassignment ElectLeaders CreatePartitions DeleteTopics CreateTopics > AUTHORIZATION_FAILED if the inter-broker verification failed. The rest of the document mentions CLUSTER_AUTHORIZATION_FAILED. > For CLUSTER_AUTHORIZATION_FAILED, this indicates an internal error for broker security setup which has nothing to do with the client, so we have no other way but returning an UNKNOWN_SERVER_ERROR to the admin client. I don't understand this. I think I don't understand this because it is not clear to me who, how and when authorization is going to work when using Envelopre{Request,Response}. Can you please add a section that explains how authorization works when envelopes are involved? -- -Jose
