[
https://issues.apache.org/jira/browse/CASSANDRA-19978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887932#comment-17887932
]
Stanislav Bychkov commented on CASSANDRA-19978:
-----------------------------------------------
I agree with the idea of sharing a single cluster for each "set" of tests. In
fact, this approach is already being used in the existing GoCQL CI GitHub job.
Spinning up a new cluster for every test would take an unnecessarily long time.
In my [PR|https://github.com/apache/cassandra-gocql-driver/pull/1780] that
integrates Testcontainers(TC), I "created" a separate "set" for tests involving
topology changes, tagged as {{{}tc{}}}. I initially set this up to wait for
maintainer feedback on where to place the fixed flaky tests. However, I noticed
there's an idea to keep tests involving topology changes in their own set, so
the {{tc}} tag can be considered a dedicated set for topology-related cases, as
there almost all tests related to topology.
When I was handling a task to fix flaky tests, I saw some issue and PRs there
are discussions regarding some CCM might get rusty with CI, as a result, those
tests had been skipped. While I believe these tests could be fixed with the
existing CCM scripts, I’ve had no issues so far with the TC setup. Also, I
removed several sleep timers, which I suspect has sped up the processes
previously handled by CCM.
I agree with Stefan’s point that since GoCQL is a Go-first project, it makes
sense to rely on Go libraries. In fact, I think it's a good practice to have
diverse approaches to similar tasks, such as choosing a runner for integration
tests. This gives flexibility in case one runner becomes flaky.
{quote} ... the huge benefit of being able to run a C* version from a git ref
so it's super easy to verify that the driver is working correctly with a
specific C* build that is not GA, we've actually done this in preparation for
certain C* releases in the past on the DataStax drivers.
{quote}
If there's a need to run a specific version of Cassandra that's not GA, TC
allows you to add a custom Dockerfile.
{quote}Benefit of not being on CCM is that a developer does not need to mess up
with Python + CCM. Believe or not, somebody finds it dredful to deal with that
when they do not need to do that at all.
{quote}
I couldn't agree more with Stefan on this. Since integrating TC, running all
integration tests locally has become much easier, eliminating the need for
additional tools and complex local environment setups.
Another advantage of using Docker containers is their ability to isolate
themselves from various local misconfigurations through features like isolated
networking, environment variables, file systems, and dependency management.
This isolation also simplifies the cleanup process after tests. Additionally,
containers enable the management of resource limits, which can be beneficial
for addressing some edge cases.
> Rewrite integration test setup in Go
> ------------------------------------
>
> Key: CASSANDRA-19978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19978
> Project: Cassandra
> Issue Type: Task
> Components: Client/gocql-driver
> Reporter: João Reis
> Priority: Normal
>
> {quote}Currently integration tests use ccm to setup a Cassandra cluster for
> testing.
> It is not easy to simulate things like topology changes, nodes joining,
> leaving, re-joining with a different IP address, etc.
> We could rewrite integration test runner using Docker API directly or using a
> library like testcontainers-go.
> {quote}
>
> https://github.com/apache/cassandra-gocql-driver/issues/1686
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
