Hi Jun, Thanks for the reply.
RE JR1: I would say the main use case is dynamic quorums, since the concept of the observer controller becomes a thing in that world. However, there is a static quorum edge case if the operator misconfigures `controller.quorum.voters`. If a new controller voter mistakenly joins the cluster, it will also persist a registration record. In my opinion, there should be a way to remove a controller registration via AdminClient CLI in all quorum modes. RE JR2: Yes, the existing command only removes the voter, but does not unregister the controller. I left it as a separate flag for now because they are "separate" operations in that being a raft voter is a subset of being a controller in dynamic quorums, but I am not opposed to making this command try to do both (remove voter and unregister the controller) by default. In my opinion, an observer controller is "useless" in that it does not participate in the leader election or replication parts of the KRaft protocol, so I see no issue with doing both operations always. However, an operator may want observer controllers around for other reasons like redundancy. Do you (or others) have any insight into how users may be configuring clusters with observer controllers? If not, I think it is okay to remove the flag and make it the default behavior of `kafka-metadata-quorum remove-controller`. RE JR3: Not exactly. The `kafka-metadata-quorum remove-controller ... --unregister` sends 2 RPCs to the active controller, one to remove a node from the voter set, and another to unregister the node. The `kafka-cluster unregister-controller` command just sends 1 RPC to the active controller to unregister the node. My motivation for having two separate commands is because `remove-controller` is associated with dynamic quorum, since the `RemoveRaftVoterRPC` will fail if the kraft.version=0. What do you think? RE JR4: I have updated the sections for the CLI commands in the KIP to add this information. RE JR5: This is describing the current implementation of the ControllerRegistrationManager, which will listen to the metadata log and send ControllerRegistrationRequest when the local node id is not registered in the log. It looks like this is slightly different from how we handle broker registration in BrokerLifecycleManager. Currently, this code path never executes because controller registrations cannot be removed. Best, Kevin Wu On Fri, Apr 17, 2026 at 2:08 PM Jun Rao via dev <[email protected]> wrote: > Hi, Kevin, > > Thanks for the KIP. A few comments. > > JR1. I guess this is only intended for dynamic KRaft quorums? If so, it > would be useful to clarify that. > > JR2. kafka-metadata-quorum remove-controller --controller-id 9990 > --controller-directory-id EXAMPLE_UUID --unregister > So, the existing remove-controller logic only changes the voter set, but > doesn't unregister the controller? Should we just always do these two > together? Is there a use case for only removing a controller from the voter > set, but not unregsitering? > > JR3. Is kafka-cluster unregister-controller equivalent to > kafka-metadata-quorum remove-controller --controller-id 9990 > --controller-directory-id EXAMPLE_UUID --unregister? > > JR4. Could you describe the underlying workflow for each new command (RPCs > sent, metadata records generated, actions taken by the controller, etc)? > > JR5. "The registration manager of an unregistered controller already > attempts to re-register with the active controller. This is to prevent > accidental unregistrations." > I don't quite understand this. Why will an unregistered controller attempt > to re-register? > > Jun > > On Fri, Apr 3, 2026 at 11:31 AM Kevin Wu <[email protected]> wrote: > > > Hi all, > > > > I would like to start a discussion on KIP-1312: Support unregistering > > controllers. Below is the KIP link. > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1312%3A+Support+unregistering+controllers > > > > Thanks, > > Kevin Wu > > >
