[
https://issues.apache.org/jira/browse/KAFKA-13517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Singh updated KAFKA-13517:
--------------------------------
Description:
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 track changes proposed in KIP-823:
https://confluentinc.atlassian.net/wiki/spaces/~953215099/pages/2707357918/KIP+Admin+describeConfigs+should+allow+fetching+specific+configurations
was:
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)
> 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 track changes proposed in KIP-823:
> https://confluentinc.atlassian.net/wiki/spaces/~953215099/pages/2707357918/KIP+Admin+describeConfigs+should+allow+fetching+specific+configurations
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
