Current state: Draft
Discussion thread: N/A
JIRA:
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
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.
group.coordinator.rebalance.protocols in 4.3. The node will log a warning if the configuration is used.group.coordinator.rebalance.protocols in 5.0.group.coordinator.rebalance.protocols should migrate to the feature versioning system using kafka-features.sh to control GroupVersion, StreamsVersion, and ShareVersion. 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.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?
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.