K8SSAND-1735 ⁃ operator not using credentials from superuserSecretRef secret

[ajprok]

temp2.txt

What happened? When starting a new cassandra cluster with a superuserSecretRef secret, the operator does not create the default k8ssandra-superuser secret, and it also does not use the credentials supplied by the secret. Cannot connect to cassandra using cqlsh & the customised credentials. Gives following error:

Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042': AuthenticationFailed('Failed to authenticate to 127.0.0.1:9042: Error from server: code=0100 [Bad credentials] message="Provided username testuser and/or password are incorrect"')})

Did you expect to see something different? On supplying a superuserSecretRef secret, we should be able to connect to the cluster using cqlsh & the credentials provided.

How to reproduce it (as minimally and precisely as possible):

Environment

• K8ssandra Operator version:

  k8ssandra/k8ssandra-operator:v1.2.0

  * Kubernetes version information:

  Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-16T15:58:47Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.7", GitCommit:"b56e432f2191419647a6a13b9f5867801850f969", GitTreeState:"clean", BuildDate:"2022-03-06T21:07:35Z", GoVersion:"go1.16.14", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:

kind cluster

• Manifests: Secret

apiVersion: v1
kind: Secret
metadata:
  name: superuser
  namespace: k8ssandra-operator
type: Opaque
data:
  username: dGVzdHVzZXIK
  password: dGVzdHdvcmQK

Deployment

apiVersion: k8ssandra.io/v1alpha1
kind: K8ssandraCluster
metadata:
  name: k8ssandra
  namespace: k8ssandra-operator
spec:
  cassandra:
    superuserSecretRef:
      name: superuser
    datacenters:
      - metadata:
          name: linode-mumbai
        racks:
          - name: rack-1
        size: 1
        storageConfig:
          cassandraDataVolumeClaimSpec:
            storageClassName: standard
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 5Gi
        serverVersion: "4.0.4"
        mgmtAPIHeap: 64Mi
        config:
          cassandraYaml:
            trickle_fsync: true
            endpoint_snitch: "GossipingPropertyFileSnitch"
            num_tokens: 4
            allocate_tokens_for_local_replication_factor: 2
          jvmOptions:
            heapSize: 1Gi

• K8ssandra Operator Logs:

Attaching logs as text file, because it is too long
[temp2.txt](https://github.com/k8ssandra/k8ssandra-operator/files/9338749/temp2.txt)

Anything else we need to know?:

┆Issue is synchronized with this Jira Story by Unito

[jsanda]

Is this still a problem? I took a look at the logs you provided. The operator was able to finish reconciling the K8ssandraCluster. Note this log statement:

1.6605824321632798e+09 INFO controller.k8ssandracluster Finished reconciling the k8ssandracluster {"reconciler group": "k8ssandra.io", "reconciler kind": "K8ssandraCluster", "name": "k8ssandra", "namespace": "k8ssandra-operator", "K8ssandraCluster": "k8ssandra-operator/k8ssandra"}

Before the operator reaches this point it makes CQL calls to Cassandra to check replication settings of system keyspaces. We therefore know the operator is able to connect to Cassandra.