kevin-wu24 commented on code in PR #22191:
URL: https://github.com/apache/kafka/pull/22191#discussion_r3683184860
##########
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:
> Should we remove the controllerId from FeatureControlManager's
quorumFeatures.quorumNodeIds()?
I'm looking at `FeatureControlManager#reasonNotSupported`, which is how we
validate the cluster members support a feature upgrade via their registrations.
It looks like we do look through the broker + controller registrations, which
is good.
From my reading, the `quorumNodeIds` check on `FeatureControlManager` L360
serves as a way to check that the static voter set members from
`controller.quorum.voters` are all registered with the cluster prior to an
upgrade. If the config is not set, then this field is an empty list.
From
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406623954#KIP1312:Supportunregisteringcontrollers-UserExperience,
and assuming the voter in question is not able to send a registration, we
should not be unregistering a member of the static voter set without removing
it from that config first. The UX guide recommends removing the controller from
the voter set config prior to unregistering it. This means the lack of a
registration from a static voter SHOULD block feature upgrades in my opinion.
Therefore, I think the `quorumNodeIds` check is correct here. What do you think?
--
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]
