Page History

...

Support for downgrades: As part of future work, we may consider adding constraints to the controller to restrict the downgrade of specific flags. Certain downgrades may be disallowed unless it was forced. For example, group_coordinator feature is tied to data schemas and EOS processing semantics that may not be forward compatible.

Rejected Alternatives

...

1. We considered the idea of using the existing AlterConfigsRequest instead of introducing a new API to update features. Reasons to decide against using it:
   1. The AlterConfigsRequest format is not well equipped to elegantly express the notion of Set<FeatureUpdate> operations. The request format is more favorable towards expressing a list of key-value pairs, where each new value replaces the existing value for the specified key. Furthermore, the response format doesn't let us conveniently return the list of finalized feature versions to the caller.
   2. AlterConfigsRequest can be issued to any broker, which is not our requirement. For the future, anything that modifies ZooKeeper needs to go through the controller. This is part of the work that we are doing to build the bridge release for KIP-500.

2. As opposed to fine-granular features, we considered the idea of exposing the notion of IBP directly to the client for discovery. There are a few issues here:

   1. We are introducing a leaky abstraction here. Users/clients (excluding clients that are brokers) have to now operate with the notion of a "broker protocol version" – this is merely a detail that's internal to a cluster of brokers behind an API.
   2. This still doesn't solve the "double roll" problem related to IBP. We would need to still solve this problem.