You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by GitBox <gi...@apache.org> on 2022/05/10 14:42:02 UTC

[GitHub] [kafka] mumrah commented on a diff in pull request #12050: KAFKA-13830 MetadataVersion integration for KRaft controller

mumrah commented on code in PR #12050:
URL: https://github.com/apache/kafka/pull/12050#discussion_r869326805


##########
core/src/main/scala/kafka/server/KafkaRaftServer.scala:
##########
@@ -102,6 +106,8 @@ class KafkaRaftServer(
       threadNamePrefix,
       controllerQuorumVotersFuture,
       KafkaRaftServer.configSchema,
+      raftApiVersions,
+      Some(bootstrapMetadata)

Review Comment:
   That's an interesting point. For the broker, on first start, it will start up without a `metadata.version`. It won't be until the bootstrapped version is written by the controller and replicated to the broker that BrokerMetadataPublisher will update the FinalizedFeatureCache. 
   
   This is probably okay though, since brokers start up in a fenced state in KRaft anyways. Since the `metadata.version` bootstrapping is done in the leader election callback on the controller, we should have the FeatureLevelRecord written out before any broker registrations occur. I think this should avoid any issues with a broker becoming unfenced before knowing what the `metadata.version` is.
   
   Does that make sense? Or did I misunderstand your question :)
   
   



-- 
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-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org