...
| Response type | Topics Section | "Brokers" Section | Comments |
|---|---|---|---|
| Successful response from KRaft controller | The 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 request | the given topics, with the expected error code | Empty | |
| Error response if no topics were given in request | the __cluster_metadata topic with the expected error code | Empty | There 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 direct.to.controller configuration
...