Page History

...

Imagine a case where the '/features' ZK node is non-existent. In such a case, when the controller starts up, it would create the ZK node for the first time (this is a blocking write that needs to succeed for the controller to continue its startup sequence). The data used to create the node, will be a map of {feature_name → {min_feature_version, max_feature_version}}. This is obtained by the controller service from the broker's supported features. This approach brings convenience to users bootstrapping a Kafka cluster for the first time (with a specific Kafka Broker release). The controller finalizes the default min/max feature version levels automatically.

...

Changes to Controller

We introduce 1 new Admin API that’s served only by the controller, and identified by the new API key: ApiKeys.UPDATE_FEATURES. This API enables transactional application of a set of cluster-wide feature updates to the ZK '/features' node (i.e. either all provided FeatureUpdate are applied to ZK, or none):

...

1. A server-side error means the '/features' ZK node is guaranteed to be left unmodified.

2. A network error, or if the client dies during the request, or if the server dies when processing the request, it means the user should assume that the application of List<FeatureUpdate> may have either succeeded or failed.

Feature version deprecation

Sometimes there can be a need to deprecate a specific feature version (see Non-goals section). This requirement translates to increasing the cluster-wide finalized minimum version level of one or more features in the ZK '/features' node. Such feature version deprecations are typically announced in advance to the Kafka community. Then, during a specific Kafka release the Controller module during it's startup sequence can be made to automatically increase the cluster-wide finalized min version level of the deprecated feature in the ZK '/features' node.

Client discovery of finalized feature versions

...