Unfortunately, the operator test is a failure due to the lack of configuration possibility

• non blocker, the init containers are OOMkilled during the start, it can be solved by editing the cassandra statefulset created by the operator to extend the limits
• blocker, it's not possible to configure the commitlog_directory explicitly. it's by default on /var/lib/cassandra/commitlog
  • it's not easy to propagate the host mounts to use 2 mountpoints /srv/cassandra and /srv/cassandra/commitlog without tweaking the kernel / rancher configuration
  • it's not possible to add a second volume on the pod description created by the operator

I will try to fallback to a quick and dirty manual configuration of cassandra in the cluster to keep the kube ops advantages

After spending some time to successfully start a cassandra cluster of 2 nodes with a declarative configuration), these are the observations:

• A service can't be used to expose the cassandra ports to the clustrer, the pod address must be used. It's because cassandra use the dns name provided as listen address
• It should work by setting the listen address to 0.0.0.0 but it's stongly recommanded to not use this in the documentation

Setting listen_address to 0.0.0.0 is always wrong.

• Using internal pod address will avoid multi DC deployment for the future

A new version of the k8ssandra operator was also released last week. It allows now to configure the init containers, but still not the commit log directory.

For this reasons, I will fallback to a "classical" puppet installation

For the record, the issues related to the commitlog_directory configuration:

• https://github.com/k8ssandra/k8ssandra/issues/351
• https://github.com/k8ssandra/k8ssandra-operator/issues/552

The puppet code is ready for review. It was updated to support multi instances deployment in anticipation of T4375.

The kubernetes cluster was not removed yet as it will probably be used for T4391.
While waiting for the review of D8236, I will focus on on it.