You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Jason Gustafson (Jira)" <ji...@apache.org> on 2021/02/19 01:08:00 UTC

[jira] [Resolved] (KAFKA-12232) Distinguish API scope by broker/controller

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