[
https://issues.apache.org/jira/browse/KAFKA-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantine Karantasis updated KAFKA-4028:
------------------------------------------
Labels: needs-kip (was: )
> Add Connect cluster ID and expose it in REST API
> ------------------------------------------------
>
> Key: KAFKA-4028
> URL: https://issues.apache.org/jira/browse/KAFKA-4028
> Project: Kafka
> Issue Type: Improvement
> Components: KafkaConnect
> Reporter: Ewen Cheslack-Postava
> Priority: Major
> Labels: needs-kip
>
> We have some basic info about the server available via GET / (currently
> version information). It'd be nice to have some additional cluster metadata
> available via the REST API (perhaps under a /cluster endpoint). A cluster ID
> would be a good starting point, although we'll need to decide whether we
> really want this as a global view of the cluster or a set of APIs that give
> you info about the individual worker (where some values should simply be
> consistent across the cluster).
> There are a couple of ways we could implement cluster IDs:
> * An entirely new config
> * If we could get some unique ID for the Kafka cluster, leverage the name of
> the config topic. This doesn't require a new worker config, but the name
> probably isn't ideal -- it might include a reasonable prefix, but will also
> often include the suffix "-config" which will look odd.
> * If we could get some unique ID for the Kafka cluster and implement
> KAFKA-3254, we could automatically generate one as (Kafka cluster ID, topic
> prefix)
> Note that some of these are assuming distributed mode. We'd have to figure
> out a scheme that can also be applied to standalone clusters. Backwards
> compatibility is also a concern since we'd rather not introduce any new
> required configs if possible.
> As this is new public API, it'll need a KIP before implementation.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
