Thanks for the KIP Colin, Here is a partial review:
1. > Even when a broker and a controller are co-located in the same JVM, they must > have different node IDs Why? What problem are you trying to solve? 2. > Node IDs must be set in the configuration file for brokers and controllers. I understand that controller IDs must be static and in the configuration file to be able to generate consensus in KIP-595. Why are the broker nodes which are observers in KIP-595 cannot discover their ID on first boot and persist their ID for consistency in future restarts? 3. > Controller processes will listen on a separate endpoint from brokers Why is this? Kafka supports multi endpoints. For example, one broker can have one endpoint for listening to connections by other brokers and another endpoint for connections from admin, producer and consumer clients. 4. > In the case of controller RPCs like AlterIsr, the controller handles this by > not sending back a response until the designated change has been persisted. Should we enumerate these RPCs? For example, we also have `ListPartitionReassignments` which is a read operation and goes directly to the controller. The naive solution would be to return the uncommitted state in the controller. 5. This KIP mentions a topic named __kafka_metadata. KIP-595 and KIP-630 mention a partition named __cluster_metadata. We should reconcile this difference. -- -Jose
