jolshan commented on code in PR #15685:
URL: https://github.com/apache/kafka/pull/15685#discussion_r1612319940
##########
core/src/main/scala/kafka/tools/StorageTool.scala:
##########
@@ -109,6 +111,52 @@ object StorageTool extends Logging {
}
}
+ private def validateMetadataVersion(metadataVersion: MetadataVersion,
config: Option[KafkaConfig]): Unit = {
+ if (!metadataVersion.isKRaftSupported) {
+ throw new TerseFailure(s"Must specify a valid KRaft metadata.version of
at least ${MetadataVersion.IBP_3_0_IV0}.")
+ }
+ if (!metadataVersion.isProduction) {
+ if (config.get.unstableMetadataVersionsEnabled) {
+ System.out.println(s"WARNING: using pre-production metadata.version
$metadataVersion.")
+ } else {
+ throw new TerseFailure(s"The metadata.version $metadataVersion is not
ready for production use yet.")
+ }
+ }
+ }
+
+ private[tools] def generateFeatureRecords(metadataRecords:
ArrayBuffer[ApiMessageAndVersion],
+ metadataVersion: MetadataVersion,
+ specifiedFeatures: Map[String,
java.lang.Short],
+ allFeatures: List[Features],
+ usesVersionDefault: Boolean): Unit
= {
+ // If we are using --version-default, the default is based on the metadata
version.
+ val metadataVersionForDefault = if (usesVersionDefault)
Optional.of(metadataVersion) else Optional.empty[MetadataVersion]()
Review Comment:
We do not. This was changed yesterday and the code was as you say in the
comment.
> Do we get the same result by passing in that metadataVersion to
feature.defaultValue()
If we follow the protocol of creating a new MV for each new feature and
making them production ready at the same time then the answer to your question
is yes. If we want to codify this and require a new MV (used only for mapping a
default) for every new feature to be created when we mark the feature as
production ready, I can switch it back to how it was yesterday.
I originally changed it in the case where we want to piggyback on the next
MV and we may mark the feature as production ready but not the MV.
--
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]
