You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Colin McCabe (Jira)" <ji...@apache.org> on 2021/12/03 01:36: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=17452681#comment-17452681 ] 

Colin McCabe commented on KAFKA-12505:
--------------------------------------

We did change over the internal logic to handle clusterId as a string, mostly for compatibility with the existing implementation.

I'm not sure if there's a big advantage to relaxing this validation, though, so maybe we should table this for now until we think of one...

> 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.20.1#820001)