Hi, Kevin, Thanks for the reply.
JR1. If this can be used for static quorum, it would be useful to document the usage pattern. I guess the user need to manually change controller.quorum.voters after deregistering the controller? JR2. If we don't have a use case for observer controller, it seems simpler to always do these two operations together. Could we just unregister the controller when handling the existing RemoveVoter request? JR3. It's a bit confusing to add the same functionality in two separate tools. It seems that kafka-cluster manages brokers, while kafka-metadata-quorum manages the controllers. Jun On Mon, Apr 20, 2026 at 12:57 PM Kevin Wu <[email protected]> wrote: > 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 > > > > > >
