Current state: Discarded
Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
BrokerApiVersionsCommand tool uses its own custom admin client to send ApiVersions requests to broker. This is the last tool that relies on code from the old
AdminClient.scala class. This tool is useful to identify what Kafka version a broker is running and which features it supports. For example, since 2.3, alterConfig has been deprecated and users should use incrementalAlterConfig instead. However there is no way to find if a broker supports this new API. Users have to attempt an incrementalAlterConfig call and if an UnsupportedOperationException is raised, fallback to alterConfig. Being able to get the supported ApiVersions per broker would simplify building robust client applications.
The plan is to expose 2 new methods in the org.apache.kafka.clients.admin.Admin interface:
With the following companion objects:
Move the existing NodeApiVersions internal class to a public package (org.apache.kafka.clients.admin) so it becomes per of the public API. This internal class is already exposed by BrokerApiVersionsCommand.
The proposal is to add support for retrieving the supported APIs in the AdminClient API. For that, the following changes are required:
- Add 2 new methods to the AdminClient API: listApiVersions(Collection) and listApiVersions(Collection, ListApiVersionsOptions)
- Add companion objects: ListApiVersionsOptions, ListApiVersionsResult
- Move existing NodeApiVersions class to org.apache.kafka.clients.admin
- Update BrokerApiVersionsCommand to use the new AdminClient methods
Compatibility, Deprecation, and Migration Plan
- The BrokerApiVersionsCommand command line tool will keep working exactly as today
- No deprecation or migration plan required