THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Imagine a case where the '/features' ZK node is non-existentABSENT. In such a case, when the controller comes up, there are 2 bootstrapping situations:
...
Case #1: If the IBP is less than migration_ibp_version (see migration section), then controller will
...
create
...
an empty '/features' ZK node
...
(this is a blocking write that needs to succeed for the controller to continue its startup sequence). Basically, when the IBP is less than migration_ibp_version, but the software has been upgraded to a state where it supports this KIP, that means the user is upgrading from an earlier version of the software. In this case, we want to start with all the features disabled and allow the user to enable them when they are ready.
Case #2: If the IBP is greater than or equal to migration_ibp_version (see migration section), then, it means the software has been upgraded to a state where it supports this KIP, and the versioning system is active. In such a case, the controller would create the ZK node for the first time
...
containing a map of {feature_name → {min_feature_version, max_feature_version}}
...
(this is a blocking write that needs to succeed for the controller to continue its startup sequence). The data is obtained by the controller service from the broker's supported features. This approach brings convenience
...
, as the controller finalizes the default min/max feature version levels automatically.
Changes to Kafka Controller
...