A. Sophie Blee-Goldman created KAFKA-18840:
----------------------------------------------
Summary: Add system test for 2-rolling-bounce bridge release
upgrade path in Streams
Key: KAFKA-18840
URL: https://issues.apache.org/jira/browse/KAFKA-18840
Project: Kafka
Issue Type: Improvement
Components: streams
Reporter: A. Sophie Blee-Goldman
Since removing eager rebalancing in 4.0 it's no longer possible to do a live
upgrade directly from 2.3 or below. Instead a double rolling bounce upgrade
path through a bridge release is required. For example one could go from 2.0 ->
3.9 -> 4.0
The original cooperative rebalancing also required a double rolling bounce to
upgrade from 2.3 or below to 2.4 or above, for which the `upgrade.from` config
is used. This config was reused for several other incompatibilities since then,
also requiring a double rolling bounce.
To help users upgrading from 2.3 or below to 4.0+ without proliferation of
rolling bounces, we recommend a special upgrade path that allows one to perform
only two rolling bounces via a bridge release in the [3.5, 3.9] range. The path
is as follows:
# first rolling bounce: set the `upgrade.from` to the origin version and
upgrade code to the bridge release version (should be between 3.5 and 3.9)
# second rolling bounce: remove the `upgrade.from` config and upgrade code to
4.0 (or whatever target version)
Note that the first rolling bounce is the same as the first step of any path
using the `upgrade.from` config, and has existing test coverage. But the second
bounce includes a situation where some nodes will be on a different version
than their `upgrade.from` config's value, while other nodes will be on a 3rd
version entirely, which is not included in any existing test coverage
We should include a system test for this specific upgrade path in the
streams_upgrade_test. We can probably piggyback on the existing #
test_rolling_upgrade_with_2_bounces and reuse much of that code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
