Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Response typeTopics Section"Brokers" SectionComments
Successful response from KRaft controllerThe topic data, if any was requested.Controller endpoint information as given in controller.quorum.voters The "direct to controller" case.
Error response from if topics were given in requestthe given topics, with the expected error codeEmpty
Error response if no topics were given in requestthe __cluster_metadata topic with the expected error codeEmptyThere is no top-level error code in MetadataResponse, so we use the __cluster_metadata topic to send back our error.

AdminClient Implementation Notes

When talking to the controllers directly, the AdminClient needs to always send its RPCs to the active controller.

There is one exception: configuring ephemeral log4j settings with incrementalAlterConfigs must be done by sending them to the specified controller node.

Compatibility, Deprecation, and Migration Plan

There should be no compatibility impact since current controllers don't handle MetadataRequest.

It's worth noting here that From a security and isolation point of view, we continue to recommend putting KRaft controllers on a separate network from Kafka clients. This is always a good idea in order to have the best security and isolation.

From a competiability point of view, there should be no impact since current controllers don't handle MetadataRequest.

Only new AdminClient implementations with KIP-919 will be able to take advantage of this feature. When attempting to talk to controllers without KIP-919 support, the calls will complete with UnsupportedVersionException, reflecting the fact that the controllers don't support KIP-919.

Rejected Alternatives

bootstrap.controllers versus configuration