[
https://issues.apache.org/jira/browse/CASSANDRA-16244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271351#comment-17271351
]
Alexander Dejanovski commented on CASSANDRA-16244:
--------------------------------------------------
Hi [~adelapena],
looking at the patch it seems that we could hide the upgraded node behavior by
timing out waiting for the message to show up each time.
Correct me if I misunderstood, but the current behavior is:
* Loop through all nodes one after the other
* Start a repair using nodetool which will timeout after 10s but is expected
to fail with a specific error message on the upgraded node
* If no exception was triggered, check that the logs contain the expected
message
* Catch the TimeoutException and assume we're dealing with a non upgraded node
Isn't it possible that the assumption we're dealing with a non upgraded node
when we get a timeout could potentially hide some edge cases where the upgraded
node doesn't behave as expected and goes into timeout? We could then possibly
get the test to succeed although we're not getting the expected behavior.
Let me know if I'm missing something.
> Create a jvm upgrade dtest for mixed versions repairs
> -----------------------------------------------------
>
> Key: CASSANDRA-16244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16244
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
> Reporter: Alexander Dejanovski
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Repair during upgrades should fail on mixed version clusters.
> We'd need an in-jvm upgrade dtest to check that repair indeed fails as
> expected with mixed current version+previous major version clusters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
