Support scyllaArgs in Helm

[fee-mendes]

Describe the bug scyllaArgs value is not respected when deploying via Helm as it is not defined within helm/scylla/templates/scyllacluster.yaml. Notice this is only for Helm deployments, it works just fine via kubectl

To Reproduce Steps to reproduce the behavior:

1. Deploy a ScyllaCluster specifying scyllaArgs as a top-level key, eg:

# Version information
scyllaImage:
  tag: 4.6.3
agentImage:
  tag: 2.6.3

# Cluster information
developerMode: true
datacenter: my-test-cluster
scyllaArgs: "--memory 1g"
racks:
- name: somewhere
  members: 1
  storage:
    capacity: 1Gi
  resources:
    limits:
      cpu: 1
      memory: 4Gi
    requests:
      cpu: 1
      memory: 4Gi

2. Deploy it using Helm: helm install scylla scylla/scylla --values examples/helm/values.cluster.yaml --create-namespace --namespace scylla
3. Check Scylla process cmdline args, the relevant arg is simply ignored:

$ kubectl -n scylla exec -it scylla-my-test-cluster-somewhere-0 -c scylla -- ps auxww | grep /usr/bin/scylla
root          37  0.7  1.7 17180016808 139140 ?  Sl   15:16   0:07 /usr/bin/scylla --log-to-syslog 0 --log-to-stdout 1 --default-log-level info --network-stack posix --developer-mode=1 --smp 1 --overprovisioned --listen-address 0.0.0.0 --rpc-address 0.0.0.0 --seed-provider-parameters seeds=10.104.13.241 --broadcast-address 10.104.13.241 --broadcast-rpc-address 10.104.13.241 --alternator-address 0.0.0.0 --blocked-reactor-notify-ms 999999999 --prometheus-address=0.0.0.0

Expected behavior scyllaArgs value should be passed as an argument to scylla container within the cluster's pod.

Logs

$ kubectl -n scylla logs scylla-my-test-cluster-somewhere-0 -c scylla | grep command
command used: "/usr/bin/scylla --log-to-syslog 0 --log-to-stdout 1 --default-log-level info --network-stack posix --developer-mode=1 --smp 1 --overprovisioned --listen-address 0.0.0.0 --rpc-address 0.0.0.0 --seed-provider-parameters seeds=10.104.13.241 --broadcast-address 10.104.13.241 --broadcast-rpc-address 10.104.13.241 --alternator-address 0.0.0.0 --blocked-reactor-notify-ms 999999999 --prometheus-address=0.0.0.0"
parsed command line options: [log-to-syslog, (positional) 0, log-to-stdout, (positional) 1, default-log-level, (positional) info, network-stack, (positional) posix, developer-mode: 1, smp, (positional) 1, overprovisioned, listen-address: 0.0.0.0, rpc-address: 0.0.0.0, seed-provider-parameters: seeds=10.104.13.241, broadcast-address: 10.104.13.241, broadcast-rpc-address: 10.104.13.241, alternator-address: 0.0.0.0, blocked-reactor-notify-ms, (positional) 999999999, prometheus-address: 0.0.0.0]

Environment:

• Platform: minikube
• Kubernetes version:

version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.1", GitCommit:"632ed300f2c34f6d6d15ca4cef3d3c7073412212", GitTreeState:"clean", BuildDate:"2021-08-19T15:39:34Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}

• Scylla version: 4.6.3-0.20220414.8bf149fdd with build-id 8d16d8972498cc769071ff25309b009eb77bf77a
• Scylla-operator version: tag: 1.7.2

[tnozicka]

(I don't think this was supported before in helm, so it isn't a regression/bug. It also nicely shows that with CRs it just makes more sense to use them directly then template everything 1:1 with helm.)

[vponomaryov]

(I don't think this was supported before in helm, so it isn't a regression/bug. It also nicely shows that with CRs it just makes more sense to use them directly then template everything 1:1 with helm.)

Yes, it was not working all the time. BUT, the Helm chart schema has it in it's definition which is the user-facing API. So, the bug is either in the wrong schema or wrong behavior if schema is correct.