4.x: Fix `CcmBridge` reporting wrong database and version

[nikagra]

Problem

CcmBridge reports usage of Apache Cassandra version 4.0.0 instead of expected distribution and version. Example (expected distribution is Scylla, version 2026.2.0~dev):

06:04:44  [INFO] 05:04:44.332 [main] INFO  c.d.o.d.api.testinfra.ccm.CcmBridge - CCM Bridge configured with Apache Cassandra version 4.0.0
06:04:44  [INFO] 05:04:44.641 [pool-3-thread-1] WARN  c.d.o.d.api.testinfra.ccm.CcmBridge - Executing: ccm create ccm_1 --scylla --id 0 -n 1:0 -v 2026.2.0~dev --config-dir=/tmp/ccm6319984212981650354

-- (source)

Task

Ensure Java driver matrix test runs correct distribution. If it is ensure CcmBridge reports the actual distribution and version (values should match the ones from the ccm create args like --scylla and -v).

[nikagra]

The code responsible for passing CCM arguments is located in run.py#L165-L172:

        if self._scylla_version:
            if self._tag.startswith('3') or self._driver_type != 'scylla':
                cmd += f" -Dscylla.version={self._scylla_version}"
            else:
                # Way it works after 4.19.0.0 `ccm.distribution` was introduced
                cmd += f" -Dccm.version={self._scylla_version} -Dccm.distribution=scylla"
                # Before 4.19.0.0 it required a flag:
                cmd += f" -Dccm.scylla"

In the case being investigated, the relevant parameters passed to main.py are:

• driver version (or tag) takes values from the list ['4.19.2', '4.19.1']
• --driver-type datastax.

According to the above code fragment, only the -Dscylla.version argument is added to the command (which aligns with what we see in the logs). Since ccm.version and ccm.distribution are not set, CcmBridge defaults to Apache Cassandra 4.0.0:

  public static BackendType DISTRIBUTION =
      BackendType.valueOf(
          System.getProperty("ccm.distribution", BackendType.CASSANDRA.name()).toUpperCase());

  public static final String CCM_VERSION_PROPERTY = System.getProperty("ccm.version", "4.0.0");

On the other hand, the fact that the very next line of the attached log still contains --scylla and -v 2026.2.0~dev contradicts the above analysis, since in order for these properties to be present, CcmBridge is expected to have proper values set:

        // omitted...
        createOptions.add("-v " + getCcmVersionString(CCM_VERSION_PROPERTY));
      }
      createOptions.addAll(Arrays.asList(DISTRIBUTION.getCcmOptions()));
      execute(
          "create",
          CLUSTER_NAME,
          "-i",
          ipPrefix,
          "-n",
          Arrays.stream(nodes).mapToObj(n -> "" + n).collect(Collectors.joining(":")),
          createOptions.stream().collect(Collectors.joining(" ")));

Note, that CCM_VERSION_PROPERTY is a final field. Also, execute function logs Executing: ... with info level, not warning level.

The reason is that another implementation of CcmBridge is used, the one from github.com/datastax/java-driver.git https://github.com/apache/cassandra-java-driver (job uses old link) which may not align with our expected behavior. As an example, it logs Executing... with either error or debug level (still not warning level though).

At this moment I'm unable to tell decidedly if CCM behaves correctly showing misleading log or if it runs Cassandra despite having --scylla argument provided given there are test failures for this driver.

Java driver matrix's logic relying not on not distribution version but on driver version and type seems suspicious and. CCM installation is shared, independently of which driver creates it, it should use same parameters if it wants to setup same cluster.