Status

Current state: DraftUnder Discussion

Discussion thread: N/A

JIRA:

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Following KIP-1022 (: Formatting and Updating Features), the group.coordinator.rebalance.protocols server configuration has become redundant. KIP-848 (New Group Coordinator), KIP-932 (share Share groups), and KIP-1071 (streams Streams rebalance protocol), and KIP-848 (group coordinator) now implement ShareVersion, StreamsVersion, and GroupVersion  now implement group.version , streams.version , and share.version  respectively. These feature versions enable cluster-wide upgrades and downgrades through kafka-features.sh, eliminating the need for server-level configuration to control feature versions.

Having a server-level configuration is problematic because individual brokers can be misconfigured, resulting in a cluster operating in a mixed state. Feature flags provide a superior alternative by ensuring cluster-wide consistency and preventing configuration drift between brokers. Moreover, the current implementation shows transitional behavior across different coordinator types. While share groups have completely decoupled from group.coordinator.rebalance.protocols, the new group coordinator and streams still rely on this configuration. This means that even when the feature version is upgraded via kafka-features.sh, the new capabilities remain unavailable unless the server configuration is also updated. This dual requirement exists because the feature flag mechanism was introduced later in the development cycle, resulting in a transitional period where both systems coexist. This can lead to user confusion when feature upgrades don't immediately enable new capabilities.

Public Interfaces

• org.apache.kafka.coordinator.group.GroupCoordinatorConfig.GROUP_COORDINATOR_REBALANCE_PROTOCOLS_CONFIG

Proposed Changes

• DeprecateThe group.coordinator.rebalance.protocols  configuration will be deprecated in Kafka 4.3. The node will log a warning if the configuration is used.
• Remove group.coordinator.rebalance.protocols in 5.0.

Compatibility, Deprecation, and Migration Plan

• Operators using group.coordinator.rebalance.protocols should migrate to the feature versioning system using kafka-features.sh to control GroupVersion, StreamsVersion, and ShareVersion.
  Documentation will provide the mapping between configuration values and equivalent feature flag settings.
• Operators should review their current group.coordinator.rebalance.protocols settings, determine the equivalent feature flag settings for GroupVersion, StreamsVersion, and ShareVersion, then use kafka-features.sh to configure cluster-wide feature levels. After setting feature flags, the deprecated configuration can be removed from broker configuration files.

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

References

• .x and removed in version 5.0, following the same approach as Share Groups. The configuration will be decoupled from feature functionality, meaning it will be accepted but ignored during the transition period. Both New Group Coordinator and Streams will follow the Share Groups model where functionality is controlled solely by group.version  and streams.version  feature via kafka-features.sh. This eliminates the dual requirement of setting both configuration and feature flags, providing a consistent experience across all coordinator types. Users should use kafka-features.sh for all feature version management, and can safely remove the configuration from their server.properties files as it no longer affects feature functionality.

Compatibility, Deprecation, and Migration Plan

For the group coordinator, after users upgrade, the system will maintain the same version as before the upgrade because feature information is persisted. Users can upgrade using kafka-features.sh without concern for the config value, as it has been decoupled from the feature version.

As for Share Groups and Streams rebalance protocol, the same applies. Additionally, since neither has reached general access yet, there are no migration concerns.

Test Plan

Rejected Alternatives

References

• KIP-848: The Next Generation of the Consumer Rebalance Protocol
KIP-1022: Formatting and Updating Features
• KIP-932: Queues for Kafka (Share Group)
• KIP-1022: Formatting and Updating Features Groups)
• KIP-1071: Rebalance Protocol for Kafka StreamsKIP-848: The Next Generation of the Consumer Rebalance Protocol