[ 
https://issues.apache.org/jira/browse/KAFKA-18840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17929023#comment-17929023
 ] 

A. Sophie Blee-Goldman commented on KAFKA-18840:
------------------------------------------------

Related to [https://github.com/apache/kafka/pull/18988/]

> 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)

Reply via email to