divijvaidya commented on code in PR #14176:
URL: https://github.com/apache/kafka/pull/14176#discussion_r1293348162
##########
core/src/main/scala/kafka/server/ControllerServer.scala:
##########
@@ -231,7 +231,7 @@ class ControllerServer(
setMetrics(quorumControllerMetrics).
setCreateTopicPolicy(createTopicPolicy.asJava).
setAlterConfigPolicy(alterConfigPolicy.asJava).
- setConfigurationValidator(new ControllerConfigurationValidator()).
+ setConfigurationValidator(new
ControllerConfigurationValidator(sharedServer.brokerConfig)).
Review Comment:
Nope, I would disagree that the scenario is complicated. For larger clusters
containing hundreds of nodes, rolling restart can take a long time. Any
functionality that we introduce in Kafka code base should be able to handle
scenarios where some brokers have features enabled and others don't. In
existing code base this is achieved by using the "features" [1]. When a broker
sends metadata to the controller, it will also send "features" that it
supports. In our situation, we need to add TS as a "feature". So during rolling
restart, controller knows that not all brokers have the correct feature and
will reject any call to enable TS for a topic. After rolling restart is
complete, controller will know that all brokers have TS feature on them, hence,
it can start enabling TS for topic.
[1]
https://github.com/apache/kafka/blob/43751d8d0521b1440a823a9430fdb0659ce7c436/core/src/main/scala/kafka/server/BrokerFeatures.scala#L33
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
