kevin-wu24 commented on code in PR #22191:
URL: https://github.com/apache/kafka/pull/22191#discussion_r3685131403
##########
metadata/src/main/java/org/apache/kafka/controller/QuorumController.java:
##########
@@ -2153,6 +2157,21 @@ public CompletableFuture<Void> registerController(
EnumSet.noneOf(ControllerOperationFlag.class));
}
+ @Override
+ public CompletableFuture<Void> unregisterController(
+ ControllerRequestContext context,
+ int controllerId
+ ) {
+ return appendWriteEvent("unregisterController", context.deadlineNs(),
+ () -> {
+ if (nodeId == controllerId) {
+ throw new InvalidRequestException("Controller cannot
unregister itself while it is active.");
+ }
+ return clusterControl.unregisterController(controllerId);
Review Comment:
`Run kafka-cluster unregister-controller` would be step 3. Stopping the
voter and removing it from all `controller.quorum.voters` configs can be done
interchangeably I believe.
That is to say, the preconditions for unregistering a controller with id X
in a static quorum are:
1. X is not present in `controller.quorum.voters`
2. X is not running (if it is it will re-register)
Ideally, we should have the same pre-requisites for dynamic quorum WRT the
voters set. I think the approach would be analogous to using
`RaftControllerNodeProvider` or `KRaftVersionAccessor` to extract raft internal
state. Maybe it is okay to file a JIRA for this as a follow-up instead, since
unregistering a live voter in either quorum mode will cause the voter to
register itself again, so the cluster can recover from that "incorrect"
operation. What do you think @junrao?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
