chia7712 commented on code in PR #14628:
URL: https://github.com/apache/kafka/pull/14628#discussion_r1674554451
##########
core/src/main/scala/kafka/tools/StorageTool.scala:
##########
@@ -60,7 +63,11 @@ object StorageTool extends Logging {
if (!metadataVersion.isKRaftSupported) {
throw new TerseFailure(s"Must specify a valid KRaft metadata
version of at least 3.0.")
}
- val metaProperties = buildMetadataProperties(clusterId, config.get)
Review Comment:
> Since we released 3.7, 3.7.1 and soon 3.8 without this validation, we
should continue to accept it in the broker startup logic so we don't break
anyone's existing cluster. But I don't see a reason why we shouldn't add the
validation back to StorageTool, to prevent new clusters being created with a
non UUID value for cluster ID. WDYT?
agree that adding uuid check back will have compatibility issue. Also, I
grep code base and don't find any uuid restriction to cluster id. Hence, I plan
to open a jira to address following changes:
1. update docs (https://kafka.apache.org/documentation/#kraft_storage) to
remind that "cluster id" can be non-uuid format after 3.7
(https://issues.apache.org/jira/browse/KAFKA-17123)
2. change the type from `uuid` to `string` fo r testing code to avoid
misunderstand. (https://issues.apache.org/jira/browse/KAFKA-17122)
3. cleanup the unused code from `StroageTool`
(https://issues.apache.org/jira/browse/KAFKA-17118)
--
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]
