Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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, and allowDowngrade 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:

  1. 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).

  2. By default, the API disallows max feature version level downgrades (Y < X) and finalized feature deletions (Y < 1). Such changes are allowed to be attempted only if the allowDowngrade flag is specifiedadditionally set in the requestNote that despite this the allowDowngrade flag being set, certain downgrades may be rejected by the controller, if it the action is deemed impossible.

  3. If any broker does not contain a required feature, this is considered an incompatibility → such a case will fail the API request.

  4. If any broker contains an additional feature that’s not required → this is not considered an incompatibility.

  5. 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).

  6. 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).

  7. 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).

...