You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Status

Current state: Draft

Discussion thread: N/A

JIRA: KAFKA-19740 - Getting issue details... STATUS

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-932 (share groups), KIP-1071 (streams rebalance protocol), and KIP-848 (group coordinator) now implement ShareVersion, StreamsVersion, and GroupVersion 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.

Public Interfaces

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

Proposed Changes

  • Deprecate group.coordinator.rebalance.protocols in 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

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