...
Then, the API implementation allows a change from X to Y in the ZK node, only if either one of the following cases is true for satisfied for the same <feature_name>
:
- Upgrade case: Y > X and Y falls within in the
[min_version, max_version]
range advertised by each live broker in the cluster.
[OR] - Downgrade case: Y < X, and Y falls in the
[min_version, max_version]
range advertised by each live broker, andallowDowngrade
flag is set in the request.
[OR] - Deletion case: Y < 1, indicating a request for feature deletion (see #2 below), and
allowDowngrade
flag is set in the request.
Note the following rules that are applied:
The usual regular usage of the API is a feature upgrade. This is by specifying a higher new max feature version level value (i.e. Y
> X)
.By default, the API disallows max feature version level downgrades (Y
< X) a
nd finalized feature deletions (Y< 1)
. Such changes are allowed to be attempted only if theallowDowngrade
flag is specifiedadditionally set in the request. Note that despite this theallowDowngrade
flag being set, certain downgrades may be rejected by the controller, if it the action is deemed impossible.If any broker does not contain a required feature, this is considered an incompatibility → such a case will fail the API request.
If any broker contains an additional feature that’s not required → this is not considered an incompatibility.
Some/all of the above logic will also be used by the broker (not just the controller) for it’s protections (see this section of this KIP).
Activating the effects of a feature version cluster-wide is left to the discretion of the logic implementing the feature (ex: can be done via dynamic broker config).
Deprecating/eliminating the presence/effects of a specific feature version cluster-wide is left to the discretion of the logic backing the feature (ex: can be done via dynamic broker config). However, it may need further external verification to ensure no entity (ex: a consumer, or a broker) is actively using the feature (see Non-goals section).
...