[ https://issues.apache.org/jira/browse/KAFKA-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Gustafson resolved KAFKA-12232. ------------------------------------- Resolution: Duplicate > Distinguish API scope by broker/controller > ------------------------------------------ > > Key: KAFKA-12232 > URL: https://issues.apache.org/jira/browse/KAFKA-12232 > Project: Kafka > Issue Type: Improvement > Reporter: Jason Gustafson > Priority: Major > > After KIP-500, not all APIs will be available on all listeners. Specifically, > there are controller-only APIs which are only accessible on the controller > listener (e.g. the Raft APIs). In general, we have three API scopes: > client: must be exposed on client listener > broker: must be exposed on inter-broker listener > controller: must be exposed on controller listener > These categories are not mutually exclusive. The `Fetch` API is required on > all listeners as an example, so we need a way to represent the scope as a set > in `ApiKeys`. > We should also put some thought into how this scope is reflected through the > ApiVersions API. I think it makes sense to only advertise APIs that can be > handled. For example, if the controller does not have a handler for the > `FindCoordinator` API, then it doesn't make sense to advertise it. > Potentially we could be even more restrictive when it comes to the > inter-broker APIs. For example, we might not need to advertise > `WriteTxnMarkers` on client-only listeners since a client should never use > this API. Alternatively, we can make it simple and just identify APIs by > controller, broker, or both. -- This message was sent by Atlassian Jira (v8.3.4#803005)