...
For any <feature_name>, the above API implementation guards against a change for the related entry in '/features'
from {"max_version_level": X}
to {"max_version_level": X’}
, unless, it notices that each live broker in the deployment advertises {"maxVersion": Y >= X’}
and {"minVersion": Z <= X’}
in it’s BrokerIdZnode
(for the same <feature_name>
).
Note the following rules that are applied:
The usual regular usage of the API is a feature upgrade. This is done by specifying a higher new max feature version level value (i.e.
X' > X)
.By default, the API disallows max feature version level downgrades (
X' < X) a
nd feature deletions (X' < 1)
. Such changes are allowed to be attempted only if theallowDowngrade
flag is specified. Note that despite thisallowDowngrade
flag being set, certain downgrades may be rejected by the controller if it 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).
...