[
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)
