THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- We need a way to map the usage of IBP in the code (in the form of a static configuration) to the usage of IBP in the new feature versioning system. To achieve this, we introduce one or more feature flags in the code. These will be used to release features which were otherwise released under the static IBP config. We illustrate the write-up below using one such a feature flag called as
ibp-feature
. For example, we will use theibp-feature
flag in the code at places wherever newer IBP values (from static configuration) are otherwise needed to be used:- The max version values for this flag will start from 1 and continue increasing for future IBP version advancements.
- The min version value for this flag will start from 1, and it is unlikely to be modified (since we rarely or almost never deprecate IBP versions).
- By this point, IBP-based decision making in the broker code will be such that:
- If the
ibp-feature
flag is finalized and if static IBP config value is >=migration_ibp_version
, then the value of theibp-feature
flag is preferred for decision making over the IBP value from static configuration. - Otherwise if the
ibp-feature
flag is not finalized yet, we continue to use the latest IBP value based on static configuration for decision making.
- If the
- We then release the
ibp-feature
flag as part of a subsequent Kafka release. The release would eventually get deployed to Kafka clusters, and, theibp-feature
flag is expected to be finalized in the cluster (via provided tooling). - Once #3 happens, all future Kafka code changes can continue to use the
ibp-feature
flag, thereby effectively stopping the use of IBP as a static configuration.
...