Page History

...

As such, we don’t support downgrades in this versioning scheme/system system (see Non-goals and Future work). So, there is a danger if the cluster operator tries to downgrade the group_coordinator feature flag from v1 to v0. This is because the stream client side shall not downgrade at all, and this would crash the EOS applications. As part of future work, we may consider adding constraints to the controller to restrict the downgrade of specific flags (unless there is a sign that it is done consciously). For example, group_coordinator feature is tied to data schemas and EOS processing semantics that’s not forward compatibleA safe practice is to first downgrade the stream clients, before downgrading  the group_coordinator feature flag.

Potential Features in Kafka

...

We do not foresee this happening once the migration is over, and IBP has been deprecated. However, it can happen that we would want to switch back to using IBP-based setup while we are in Phase #3 above (for example, due to an unprecedented issue). This will be supported, because we deprecate IBP only in Phase #4 above. To "downgrade", a user would first need one rolling restart of the cluster to reduce the IBP to the required version. Then another rolling restart to change the binary. Note that each feature will have its own set of requirements to make this possible (in some cases, it may not be possible), but this is outside the scope of this document.

Future work

Support for downgrades: As part of future work, we may consider adding constraints to the controller to restrict the downgrade of specific flags (unless there is a sign that it is done consciously). For example, group_coordinator feature is tied to data schemas and EOS processing semantics that may not be forward compatible.

Rejected Alternatives

<?>