flux2 icon indicating copy to clipboard operation
flux2 copied to clipboard

HelmRelease: valuesFrom does not set values

Open schmidp opened this issue 1 year ago • 4 comments

Describe the bug

I am trying to set the access_key and secret_key of a prometheus receiver.

The values I set via secrets in alertmanager.config.global work. The values with the paths

    targetPath: alertmanager.config.receivers[4].sns_configs[0].sigv4.access_key
    targetPath: alertmanager.config.receivers[4].sns_configs[0].sigv4.secret_key

Maybe I did not understand the documentation, but I also tried asking chatgpt and it agrees that the paths should be correct.

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: prometheus
  namespace: flux-system
spec:
  interval: 5m
  install:
    createNamespace: true
    crds: Create
  upgrade:
    crds: CreateReplace
  targetNamespace: prometheus
  releaseName: prometheus
  chart:
    spec:
      chart: kube-prometheus-stack
      version: "48.3.2"
      sourceRef:
        kind: HelmRepository
        name: prometheus-community
        namespace: flux-system
      interval: 1m
  valuesFrom:
  - kind: Secret
    name: alerts-slack-url
    valuesKey: address
    targetPath: alertmanager.config.global.slack_api_url
    optional: false
  - kind: Secret
    name: alerts-smtp-config
    valuesKey: smarthost
    targetPath: alertmanager.config.global.smtp_smarthost
    optional: false
  - kind: Secret
    name: alerts-smtp-config
    valuesKey: username
    targetPath: alertmanager.config.global.smtp_from
    optional: false
  - kind: Secret
    name: alerts-smtp-config
    valuesKey: username
    targetPath: alertmanager.config.global.smtp_auth_username
    optional: false
  - kind: Secret
    name: alerts-smtp-config
    valuesKey: password
    targetPath: alertmanager.config.global.smtp_auth_password
    optional: false
  - kind: Secret
    name: alerts-sns-config
    valuesKey: access_key
    targetPath: alertmanager.config.receivers[4].sns_configs[0].sigv4.access_key
  - kind: Secret
    name: alerts-sns-config
    valuesKey: secret_key
    targetPath: alertmanager.config.receivers[4].sns_configs[0].sigv4.secret_key
  values:
    alertmanager:
      config:
        # global:
          # smtp_smarthost: smtp.example.com:587   # set by valuesFrom
          # smtp_from: "[email protected]"  # set by valuesFrom
          # smtp_auth_username: "alertmanager"     # set by valuesFrom
          # smtp_auth_password: "password"         # set by valuesFrom
          # slack_api_url: "url"                   # set by valuesFrom
        route:
          group_by: ['namespace']
          group_wait: 30s
          group_interval: 5m
          repeat_interval: 12h
          receiver: 'null'
          routes:
          - receiver: "sns-cluster-receiver"
            matchers:
              - severity =~ "critical"
        receivers:
          - name: 'null'
          - name: slack-receiver
            slack_configs:
              - channel: "#xxx-bot"
                send_resolved: true
          - name: slack-noisy-receiver
            slack_configs:
              - channel: "#xxx-noisy"
                send_resolved: true
          - name: email-receiver
            email_configs:
              - to: "xxx@xxx"
                send_resolved: true
          - name: sns-cluster-receiver
            sns_configs:
            - sigv4:
                region: eu-west-1
                # access_key: override    # set by valuesFrom
                # secret_key: withvalues  # set by valuesFrom
              topic_arn: arn:aws:sns:eu-west-1:xxx:alerts

Steps to reproduce

  1. Apply the helm chart.
  2. Check the contents of /etc/alertmanager/config_out/alertmanager.env.yaml in the alert manager pod
  3. See that access_key and secret_key are missing:
- name: sns-cluster-receiver
  sns_configs:
  - sigv4:
      region: eu-west-1
    topic_arn: arn:aws:sns:eu-west-1:xxxx:alerts

Expected behavior

  • name: sns-cluster-receiver sns_configs:
    • sigv4: region: eu-west-1 access_key: value secret_key: value topic_arn: arn:aws:sns:eu-west-1:xxxx:alerts

Screenshots and recordings

No response

OS / Distro

k8s ubuntu jammy

Flux version

2.0.0

Flux check

► checking prerequisites ✗ flux 2.0.0 <2.0.1 (new version is available, please upgrade) ✔ Kubernetes 1.27.4+k3s1 >=1.24.0-0 ► checking controllers ✔ helm-controller: deployment ready ► ghcr.io/fluxcd/helm-controller:v0.35.0 ✔ image-automation-controller: deployment ready ► ghcr.io/fluxcd/image-automation-controller:v0.35.0 ✔ image-reflector-controller: deployment ready ► ghcr.io/fluxcd/image-reflector-controller:v0.29.0 ✔ kustomize-controller: deployment ready ► ghcr.io/fluxcd/kustomize-controller:v1.0.0 ✔ notification-controller: deployment ready ► ghcr.io/fluxcd/notification-controller:v1.0.0 ✔ source-controller: deployment ready ► ghcr.io/fluxcd/source-controller:v1.0.0 ► checking crds ✔ alerts.notification.toolkit.fluxcd.io/v1beta2 ✔ buckets.source.toolkit.fluxcd.io/v1beta2 ✔ gitrepositories.source.toolkit.fluxcd.io/v1 ✔ helmcharts.source.toolkit.fluxcd.io/v1beta2 ✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1 ✔ helmrepositories.source.toolkit.fluxcd.io/v1beta2 ✔ imagepolicies.image.toolkit.fluxcd.io/v1beta2 ✔ imagerepositories.image.toolkit.fluxcd.io/v1beta2 ✔ imageupdateautomations.image.toolkit.fluxcd.io/v1beta1 ✔ kustomizations.kustomize.toolkit.fluxcd.io/v1 ✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2 ✔ providers.notification.toolkit.fluxcd.io/v1beta2 ✔ receivers.notification.toolkit.fluxcd.io/v1 ✔ all checks passed

Git provider

No response

Container Registry provider

No response

Additional context

No response

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct

schmidp avatar Aug 21 '23 20:08 schmidp

Updating to flux 2.0.1 did not help:

√ ~ % flux check
► checking prerequisites
✔ Kubernetes 1.27.4+k3s1 >=1.24.0-0
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v0.35.0
✔ image-automation-controller: deployment ready
► ghcr.io/fluxcd/image-automation-controller:v0.35.0
✔ image-reflector-controller: deployment ready
► ghcr.io/fluxcd/image-reflector-controller:v0.29.1
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.0.1
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v1.0.0
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v1.0.1
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta2
✔ buckets.source.toolkit.fluxcd.io/v1beta2
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1beta2
✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1
✔ helmrepositories.source.toolkit.fluxcd.io/v1beta2
✔ imagepolicies.image.toolkit.fluxcd.io/v1beta2
✔ imagerepositories.image.toolkit.fluxcd.io/v1beta2
✔ imageupdateautomations.image.toolkit.fluxcd.io/v1beta1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta2
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed

schmidp avatar Aug 21 '23 20:08 schmidp

.spec.values are merged in last, and use the default behavior of Helm for merging list values which means they are overwritten in your example with the full list.

hiddeco avatar Aug 21 '23 22:08 hiddeco

@hiddeco hm, I am having a hard time grasping this apprently. Are you saying I can't set anything past receivers?

I thought helm supports accessing list items:

As of Helm 2.5.0, it is possible to access list items using an array index syntax. For example, --set servers[0].port=80 becomes:

servers:
  - port: 80

Multiple values can be set this way. The line --set servers[0].port=80,servers[0].host=example becomes:

servers:
  - port: 80
    host: example

schmidp avatar Aug 22 '23 06:08 schmidp

If you move the whole of receivers into a .spec.valuesFrom item before the last two entries, it should work.

The problem is that at present, .spec.values.alertmanager.config.receivers overwrites the last two .spec.valuesFrom items.

hiddeco avatar Aug 22 '23 08:08 hiddeco