Page History

...

1. We introduce 1 new API in the broker RPC interface (see this section). This is the new ApiKeys.UPDATE_FEATURES (schema) that can only be served successfully by the controller.
2. We introduce few optional fields in the ApiVersionsResponse containing the cluster-wide finalized feature metadata, feature metadata epoch, and the broker's supported features (see this section).
3. We introduce 2 new APIs in the Admin interface to describe/addOrUpdate/delete features (see this section). Underneath covers, these exercise the APIs mentioned above.

When to use a 'feature', and what are the common use cases?

...

Guidelines and common workflows

With the newly proposed feature versioning system in this KIP, it becomes quite important to understand when to use it, and when not to.

• As part of Kafka operations, there are occasions when it becomes paramount to safely activate certain breaking changes introduced by a newer Broker version. Such changes become good candidates to be released behind a feature flag . The max feature version level can be safely finalized (using the provided mechanism in this KIP), after the cluster-wide deployment of the required Broker version. Whenever the underlying breaking change is activated by the cluster operator, the system provides a guarantee that it will not bring ill effects to the Broker cluster or the clients.
  Note that a "breaking change" typically happens whenever the underlying logic has introduced a different concept (such as a message type, or a new field in a protocol) which only certain newer versions of the Broker code can understand/process. The older Broker versions could consider the change to be alien i.e. the older Broker versions would exhibit undefined or terminal behavior if they notice effects of the breaking change. Similarly, Kafka clients could exhibit undefined behavior if they activate a feature version assuming all Brokers support it, while some don't.
• As a guideline, min/max supported feature version values should be modified if and only if the change is a breaking change. Non-breaking changes could still be made to the Broker code without modifying the feature version values.
• Most common workflow for the feature versioning system would involve finalizing upgrades to max feature version levels for all features, after completing the release of a new Kafka Broker binary on a cluster. This is explained  under Regular CLI tool usage section.

Use case: group_coordinator feature flag (for KIP-447)

...