[
https://issues.apache.org/jira/browse/KAFKA-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350973#comment-14350973
]
Gwen Shapira commented on KAFKA-2003:
-------------------------------------
Something like that :)
1. We may need two types of "version": Git version (i.e. branch, tag or even
commit hash) and numerical version (0.8.2.0, 0.8.3.0, etc) for the upgrade
configuration.
2. Also, perhaps Dockers can be used to avoid compiling old versions (i.e.
prepare docker images for releases and use those?)
3. We need to check the rolling upgrade itself. So something like:
* bring up n <from_version> brokers, do a sanity check with <from_version>
clients
* bring down one broker and replace with <to_version> broker. check that
"everything is ok"
* replace rest of brokers. check again.
* bring down one broker, bump version in config file and start it. check again.
* bump version for the rest. check again.
<continue with the client tests from here>
Looking at this, maybe we need to start by developing something that can "check
that everything is ok" :)
> Add upgrade tests
> -----------------
>
> Key: KAFKA-2003
> URL: https://issues.apache.org/jira/browse/KAFKA-2003
> Project: Kafka
> Issue Type: Improvement
> Reporter: Gwen Shapira
> Assignee: Ashish K Singh
>
> To test protocol changes, compatibility and upgrade process, we need a good
> way to test different versions of the product together and to test end-to-end
> upgrade process.
> For example, for 0.8.2 to 0.8.3 test we want to check:
> * Can we start a cluster with a mix of 0.8.2 and 0.8.3 brokers?
> * Can a cluster of 0.8.3 brokers bump the protocol level one broker at a time?
> * Can 0.8.2 clients run against a cluster of 0.8.3 brokers?
> There are probably more questions. But an automated framework that can test
> those and report results will be a good start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
