You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Igor Soarez (Jira)" <ji...@apache.org> on 2021/10/28 10:55:00 UTC
[jira] [Commented] (KAFKA-12505) Should kafka-storage.sh accept a
non-UUID for its --cluster-id parameter?
[ https://issues.apache.org/jira/browse/KAFKA-12505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435335#comment-17435335 ]
Igor Soarez commented on KAFKA-12505:
-------------------------------------
Is this question/issue still valid? StorageTool [does not seem to accepting non-UUIDs|https://github.com/apache/kafka/blob/16b2d4f3a7864aabb7c438268eeea8d602b9299c/core/src/main/scala/kafka/tools/StorageTool.scala#L194-L199].
Should this be closed?
> Should kafka-storage.sh accept a non-UUID for its --cluster-id parameter?
> -------------------------------------------------------------------------
>
> Key: KAFKA-12505
> URL: https://issues.apache.org/jira/browse/KAFKA-12505
> Project: Kafka
> Issue Type: New Feature
> Reporter: Ron Dagostino
> Priority: Minor
> Labels: kip-500
>
> Should StorageTool support accepting non-UUIDs via its --cluster-id argument? One purpose of the tool is to minimize the chance that a broker could use data from the wrong volume (i.e. data from another cluster). Generating a random UUID via the --random-uuid parameter encourages using a globally unique value for every cluster and is consistent with the behavior today with ZooKeeper, whereas allowing a non-UUID here would increase the chance that someone could reuse a Cluster ID value across clusters and short-circuit the risk mitigation that this tool provides.
> Discuss...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)