...
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):
...
A server-side error means the
'/features'
ZK node is guaranteed to be left unmodified.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
...