chia7712 commented on code in PR #14628:
URL: https://github.com/apache/kafka/pull/14628#discussion_r1677634548
##########
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:
I feel the most important thing is "Had we ever convert cluster id from
string to UUID"? If the answer is YES, we ought to add the check back to
`StorageTool` and then announce that the cluster id written by 3.7.0 and 3.7.1
is not validated according to UUID format.
Fortunately, I don't notice that usage (string -> UUID) currently. Hence,
the compatibility issue happens in `StorageTool`: Should we allow user to use
non-uuid cluster id to format? If no, we need to handle the compatibility issue
and the conflicts of base64 encoding. If yes, the side effect is ... user will
use shorter/longer string? Sorry for my poor imagination :cry:
At any rate, we are going to release 3.8.0. Hence, it would be nice to have
a decision ASAP.
--
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]
