Status
Current state: Under Discussion
Discussion thread: discussion thread
JIRA: KAFKA-7975
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
We still have some users using very old Kafka client libraries, such as Kafka 8 and Kafka 9. We need a mechanism to force users to upgrade their client libraries, and forbid outdated client libraries.
The old libraries are still supported by the latest brokers, but can cause problems when we starting using some new features. Some examples are:
- Kafka 8 / 9 / 10 consumer hangs when the message contains message header ( )
- LZ4 is not correctly handled in Kafka 8 and Kafka 9 ( )
- Performance penalty of converting message format from V3 to V1 or V2 for the old consumers (KIP-31 - Move to relative offsets in compressed message sets)
In general, we think it's reasonable to give cluster administrator the capability to forbid old client library versions.
In this KIP, we propose to add a new broker configuration to specify the minimum client version.
Public Interfaces
A public interface is any change to the following:
Configuration
Add a new broker configuration:
Name | Description | Type | Default | Importance | Dynamic Update Mode |
---|---|---|---|---|---|
min.api.version | Minimum API versions specified in a list of coma-separated <api-name>:<version> pairs. Client requests older than the specified versions will be rejected by the broker. For example, "Fetch: 5" rejects fetch requests from Kafka 0.10 and earlier clients. For the APIs that are not specified in this list, the min version is 0. Valid API names and versions can be found in Kafka protocol guide | string | "" | low | cluster-wide |
Binary log format
No
The network protocol and api behavior
Client requests older than the specified versions will be rejected by the broker.
Any class in the public packages under clientsConfiguration, especially client configuration
No
Monitoring
No
Command line tools and arguments
No
- Anything else that will likely break existing users in some way when they upgrade
No
Proposed Changes
All the changes of this KIP are in Kafka broker:
- Add min.api.version configuration in Kafka broker
- Allow dynamic update of min.api.version configuration
- Reject the API requests of older versions
Compatibility, Deprecation, and Migration Plan
- What impact (if any) will there be on existing users?
No impact to the users that are not using user-defined authorizer. For the users that are using user-defined authorizer, they will have to modify their authorizer code to use the new interface.
Rejected Alternatives
Alternative 1 - Provide api versions to authorizer
Provide client API version to authorizer. So that, the user-defined authorizer can block clients based on api versions. This is more flexible. But there are 2 concerns: 1) Blocking old clients is not a security issue. It doesn't make much sense to add this feature to authorizer. 2) For most users, it's easier to set a broker configuration than write a user-defined authorizer.