hi Jose Thanks for sharing. I have a question.
> To my knowledge this information is not available to the Admin client. We propose to use `Admin#describeConfigs` to get the configs for specific controller if the bootstrap.controllers is configured. This approach is similar to what `MetadataQuorumCommand` does, and the difference is `MetadataQuorumCommand` read those configs from local file and this KIP gets those configs by `Admin#describeConfigs` Please correct me if I misunderstand your point. Best, Chia-Ping On 2025/04/02 21:04:27 José Armando García Sancio wrote: > Hi Kuan, > > I took a look at your KIP and thought about the problem and possible > solutions. > > For the add-controller command, the active controller needs to know > the new controller's id, directory id and endpoints for the default > listener. As you mentioned in your KIP the user can provide the id > using the --controller-id flag. This seems reasonable since this is a > value that they generate and understand. For directory id, I think we > can make it optional in the RPC but the kraft leader can look it up in > the in-memory state stored for all replicas (observers). For the > endpoint, things get tricky. This needs to be an endpoint that the > network client used by KRaft knows how to connect and authenticate > against. The network client used by kraft is configured to use the > protocol described for the first listener in > controller.listener.names. > > To my knowledge this information is not available to the Admin client. > If we want to make this information available to the Admin client, I > think that the best RPC to do that is the DescribeCluster RPC. > Unfortunately, that RPC only returns the endpoints that are associated > with the port (listener) that was used to contact the bootstrap > controller (--bootstrap-controller) which may not be the endpoint > configured for the first listener in controller.listener.names. The > other issue is that the DescribeCluster RPC doesn't return controller > endpoints if the bootstrap server (--bootstrap-server) is used. The > DescribeCluster RPC can be extended so that it returns all endpoints > for all nodes (controller and brokers). > > Another way to solve this, is to make the endpoints optional. In the > current implementation all controllers send a controller registration > request to the active controller even if they are not voters (cannot > become active controller). This information is stored in the > ClusterImage. The endpoints stored in ClusterImage can be used to > populate the request sent to KafkaRaftClient. > > For the remove-controller command, the active controller needs to know > the old controller's id and directory id. We can make the directory id > optional. I think this is okay since kraft guarantees that id is > unique in the voter set. Not specified the directory id is not as safe > and idempotent but it is up to the user to opt in. We can make that > clear by the description for remove-controller and --controller-uuid. > > What do you think? > -- > -José >
