...

The ConfigResource class is made up of two fields, name of the entity (“topic-1”, “broker-1” etc) and type of the entity (BROKER, TOPIC etc). DescribeConfigsOptions allows use users to specify whether to fetch config synonyms and their documentation. The api response contains all configurations for the specified entities.

...

This results in boilerplate code for all users of AdminClient::describeConfigs api, in addition to  being wasteful use of resource. It becomes painful for large clusters where to fetch one configuration of all topics, we need to fetch all configuration of all topics, which can result in huge response. Alternatively, request can be batched, but then one api request gets broken down in tens if not hundred of api request requests depending on batch size, complicating error handling and retries.

This is also a usability issue when running kafka-configs command which returns all configurations and then user need to either scan or filter for property that they are interested in-topics is used with --describe option and no topic name is provided. We get all configurations of all the topics, where a user may only be interested in only one or few of the configurations. For kafka-topics command we also need a way to skip getting configuration so that partition information of all topics can be fetched w/o fetching their configuration.

We need to a way to specify ConfigurationKeys parameter that DescribeConfigsResource takes to bring AdminClient::describeConfigs api to parity with DescribeConfigsResource and allow AdminClient’s users to specify configuration keys that they are interested in.

In addition we need to add same option to kafka-configs command topics command line utility so that users of the tool don’t need to fetch all configurations when they are interested in only a few or none of them.

Public Interfaces

...