[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[
https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479683#comment-17479683
]
Caleb Rackliffe edited comment on CASSANDRA-16262 at 1/20/22, 9:33 PM:
---
I attempted to build the branch again this afternoon:
1.) Cleared local maven cache
2.) Moved aside existing {{settings.xml}}
3.) git clean -fxd && ant realclean && ant jar && ant build-test && ant
generate-idea-files
Got the following:
{noformat}
[retry] Attempt [0]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[retry] Attempt [1]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[retry] Attempt [2]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283036#comment-17283036 ] Alex Petrov edited comment on CASSANDRA-16262 at 2/17/21, 9:18 AM: --- Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these four issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 * NPE in Slice#make on RT + partition deletion reconciliation: https://issues.apache.org/jira/browse/CASSANDRA-16453 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. I feel that we shouold invest into automating tests that combine multiple features in different ways. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. was (Author: ifesdjeen): Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. I feel that we shouold invest into automating tests that combine multiple features in different ways. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283036#comment-17283036 ] Alex Petrov edited comment on CASSANDRA-16262 at 2/11/21, 1:58 PM: --- Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. I feel that we shouold invest into automating tests that combine multiple features in different ways. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. was (Author: ifesdjeen): Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. I feel it is that we invest into automating tests that combine multiple features in different ways. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283036#comment-17283036 ] Alex Petrov edited comment on CASSANDRA-16262 at 2/11/21, 1:58 PM: --- Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. I feel it is that we invest into automating tests that combine multiple features in different ways. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. was (Author: ifesdjeen): Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. Moreover, I feel it is counter-productive to sit and manually produce scenarios that combine multiple features, and we should instead invest into automating this labour. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283036#comment-17283036 ] Alex Petrov edited comment on CASSANDRA-16262 at 2/11/21, 1:57 PM: --- Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. Moreover, I feel it is counter-productive to sit and manually produce scenarios that combine multiple features, and we should instead invest into automating this labour. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. was (Author: ifesdjeen): Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283036#comment-17283036 ] Alex Petrov edited comment on CASSANDRA-16262 at 2/11/21, 1:55 PM: --- Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at least these three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. was (Author: ifesdjeen): Given latest data points I would strongly advise against excluding this ticket from 4.0. Running Harry for a relatively short amount of time, we've been able to hit at three issues: * Group By in-jvm paging issue: https://issues.apache.org/jira/browse/CASSANDRA-16427 * Group By breaks range tombstone closer: https://issues.apache.org/jira/browse/CASSANDRA-16431 * Reverse iteration + paging: https://issues.apache.org/jira/browse/CASSANDRA-16435 I think we would've hit the first one without a fuzz tool, since it was a relatively obvious one, but looking at the output from Harry it was almost immediately clear what's going on, so I still consider its output useful. Amount of human labour involved into producing scenarios that would trigger the issues such as the other two is quite significant. As of now, we can't even continue further testing of group by or reverse iteration with paging because we're constantly hitting these two issues. It can be that we won't hit any other ones, but I think we should at least exhaust the ability of current generators and models to find bugs, especially given they are rather simple compared to what we'd like to achieve in the future, and they're already available. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17274013#comment-17274013 ] Jeremiah Jordan edited comment on CASSANDRA-16262 at 1/28/21, 9:41 PM: --- If you think that we have covered testing things in the face of operational events, then I would be ok with that. But this is very important: bq. What remains is verifying the distributed read and write paths in the face of common operational events, namely node restarts, bootstrapping, decommission, and cleanup. So if we are not covering testing of those operational events then I would be against skipping this. was (Author: jjordan): If we think that we have covered testing things in the face of operational events, then I would be ok with that. But this is very important: bq. What remains is verifying the distributed read and write paths in the face of common operational events, namely node restarts, bootstrapping, decommission, and cleanup. So if we are not covering testing of those operational events then I would be against skipping this. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
