[
https://issues.apache.org/jira/browse/KAFKA-18840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-18840.
--------------------------------------------
Resolution: Invalid
Closing this as invalid – after further inspection it seems if we want to fully
drop support for eager we need to ensure the version being upgraded from does
not have the `upgrade.from` config set to anything 2.3 or below, which means
the 2-rolling-bounce upgrade path described here is not possible and 3 rolling
bounces are required after all. See description in
[https://github.com/apache/kafka/pull/18988] for the recommended upgrade path
> 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
> Priority: Major
>
> 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)
