HelmRelease: valuesFrom does not set values

[schmidp]

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

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

[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

[hiddeco]

.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.

[schmidp]

@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

[hiddeco]

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.

[Preisschild]

This seems to be a duplicate of #2330

It should be fixed with and the expected behavior should occur on the latest master

fluxcd/helm-controller#1060