Thanks Jose for the questions! On Thu, Apr 16, 2020 at 12:33 PM Jose Garcia Sancio <jsan...@confluent.io> wrote:
> 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 > > According to the draft Raft quorum KIP <https://cwiki.apache.org/confluence/display/KAFKA/KIP-595%3A+A+Raft+Protocol+for+the+Metadata+Quorum>, we are going to reuse the broker.id as the id for each broker participating inside the metadata quorum, either it is a voter or observer. So the controller.id embedded inside metadata response should still be valid for controller communication IIUC. As for Kafka Controller Quorum expose and implement all of the RPCs I think I also need a bit more context from you, as I think the controller logic is agnostic to the metadata log replication, which means the handling for these mutation RPCs shall be the same as the existing implementations for ZK based controller, not sure if this answers your question? > > 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? > Addressed the inconsistent error code. The authorization for EnvelopeRequest shall be the same as other requests which require CLUSTER permission, so break down as: 1. Who: the controller broker 2. How: the same as verifying other RPCs requiring CLUSTER permission, for example LeaderAndIsrRequest 3. When: during the EnvelopeRequest processing Will add more details for that context. > -- > -Jose >
