[
https://issues.apache.org/jira/browse/KAFKA-13517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Singh updated KAFKA-13517:
--------------------------------
Summary: Update Admin::describeConfigs to allow fetching specific
configurations (was: Add ConfigurationKeys to ConfigResource class)
> Update Admin::describeConfigs to allow fetching specific configurations
> -----------------------------------------------------------------------
>
> Key: KAFKA-13517
> URL: https://issues.apache.org/jira/browse/KAFKA-13517
> Project: Kafka
> Issue Type: Improvement
> Components: clients
> Affects Versions: 2.8.1, 3.0.0
> Reporter: Vikas Singh
> Assignee: Vikas Singh
> Priority: Major
>
> A list of {{ConfigResource}} class is passed as argument to
> {{AdminClient::describeConfigs}} api to indicate configuration of the
> entities to fetch. The {{ConfigResource}} class is made up of two fields,
> name and type of entity. Kafka returns *all* configurations for the entities
> provided to the admin client api.
> This admin api in turn uses {{DescribeConfigsRequest}} kafka api to get the
> configuration for the entities in question. In addition to name and type of
> entity whose configuration to get, Kafka {{DescribeConfigsResource}}
> structure also lets users provide {{ConfigurationKeys}} list, which allows
> users to fetch only the configurations that are needed.
> However, this field isn't exposed in the {{ConfigResource}} class that is
> used by AdminClient, so users of AdminClient have no way to ask for specific
> configuration. The API always returns *all* configurations. Then the user of
> the {{AdminClient::describeConfigs}} go over the returned list and filter out
> the config keys that they are interested in.
> This results in boilerplate code for all users of
> {{AdminClient::describeConfigs}} api, in addition to being wasteful use of
> resource. It becomes painful in large cluster case where to fetch one
> configuration of all topics, we need to fetch all configuration of all
> topics, which can be huge in size.
> Creating this Jira to add same field (i.e. {{{}ConfigurationKeys{}}}) to the
> {{ConfigResource}} structure to bring it to parity to
> {{DescribeConfigsResource}} Kafka API structure. There should be no backward
> compatibility issue as the field will be optional and will behave same way if
> it is not specified (i.e. by passing null to backend kafka api)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
