Fix configuration merging when using existingCommunicationsSecretName

[pkosiec]

Description

Changes proposed in this pull request:

• Fix configuration merging when using existingCommunicationsSecretName
• Do not create unused ConfigMaps when using remote config

Testing

See the instruction in #1273 and test the values:

existingCommunicationsSecretName: "comm-config.yaml"
settings:
  clusterName: "devops.azure.akelius.com"
sources:
  k8s-custom:
    botkube/kubernetes:
      config:
        event:
          types:
            - error
        namespaces:
          include:
            - kube-infrastructure
        resources:
          - type: v1/pods
      context:
        rbac:
          group:
            prefix: ""
            static:
              values:
                - botkube-plugins-default
            type: Static
      enabled: true
    displayName: Kubernetes Errors Kube Infra

resources:
  limits:
    cpu: 100m
    memory: 512Mi
  requests:
    cpu: 10m
    memory: 136Mi

Also, test the following scenarios:

• Remote config

• Using default Communications secret - you can simply use

communications:
  'default-group':
    socketSlack:
      enabled: true
      channels:
        'default':
          name: 'k8s_devops_azure'
          bindings:
            sources:
              - k8s-custom
      botToken: 'xoxb-'
      appToken: 'xapp-'
settings:
  clusterName: "devops.azure.akelius.com"
sources:
  k8s-custom:
    botkube/kubernetes:
      config:
        event:
          types:
            - error
        namespaces:
          include:
            - kube-infrastructure
        resources:
          - type: v1/pods
      context:
        rbac:
          group:
            prefix: ""
            static:
              values:
                - botkube-plugins-default
            type: Static
      enabled: true
    displayName: Kubernetes Errors Kube Infra

resources:
  limits:
    cpu: 100m
    memory: 512Mi
  requests:
    cpu: 10m
    memory: 136Mi

Related issue(s)

Resolves #1273

[josefkarasek]

lgtm 👍

[voriol]

When updating my helm chart to the latest version, 1.8.0 I got the following error:

Error: template: sre-botkube/charts/botkube/templates/persistent-config.yaml:6:23: executing "sre-botkube/charts/botkube/templates/persistent-config.yaml" at <index $secret.data "comm_config.yaml">: error calling index: index of untyped nil

Reviewing the latest changes I see that the line it refers to was changed in this commit

fdb389c#diff-e694b58be4de3f2b3d147e65317458bbbc0f5319bd07c703d80dc3b05bb5d1b7

Specifically, on line 6:

{{- $data := b64dec (index $secret.data "comm_config.yaml") -}}

This is the secret content:

apiVersion: v1
kind: Secret
metadata:
  name: botkube-communications
stringData:
  comm_config.yaml: |
    communications:
      default-group:
        ## Settings for Slack with Socket Mode.
        ...etc

I am doing something wrong?

Thanks

[pkosiec]

Hey @voriol,
As you can see in the line above, the existing Secret's data field is used: {{- $secret := lookup "v1" "Secret" .Release.Namespace .Values.existingCommunicationsSecretName | default dict }}.
you provided a snippet with the stringData, so I assume this is how you create the Secret. We'd need to check the actual Secret in the cluster, as the stringData map is encoded to data.

• Are you sure the existingCommunicationsSecretName value in Helm chart is valid?
• Can you get the secret with name defined in the existingCommunicationsSecretName via kubectl and see if the data map contains comm_config.yaml?

If that needs further investigation, please create a separate issue and mention me there, I'll try to help. Cheers!

[voriol]

Hi @pkosiec,

I think I have all the ingredients for it to work, that's why I don't understand where the problem could be.

• helm dependencies:

dependencies:
- name: botkube
  version: "1.8.0"
  repository: "https://charts.botkube.io/"

• values:

botkube:
  existingCommunicationsSecretName: "botkube-communications"

• secret / data map:

$ k get secret botkube-communications -n botkube -o jsonpath='{.data}' 
{"comm_config.yaml":"base64encoded..."

Thanks!

[pkosiec]

@voriol Let's continue our discussion in #1376 👍