feat: add checksum support for external ConfigMap usage

[elimayost]

Summary

This PR adds support for triggering DaemonSet pod restarts when using
externally managed ConfigMaps via extraFilesConfigMapNameOverride.

Currently, the chart computes a checksum only from the internally
managed ConfigMap. When users override the ConfigMap name, there is no
mechanism to trigger a rollout when the external configuration changes.

Changes

• Introduced new helper: fluentd.configChecksum
• Updated DaemonSet template to conditionally include:

checksum/config: <value>

• Added support for:
  • Using a user-provided checksum via extraFilesConfigMapChecksum
  • Falling back to hashing the rendered ConfigMap when no override
    is used
• Updated values.yaml to document:
  • extraFilesConfigMapChecksum

Behavior

Default (no override)

• Checksum is computed from the rendered
  fluentd-configurations-cm.yaml
• DaemonSet includes checksum annotation → pods restart on config
  changes

External ConfigMap usage

When:

extraFilesConfigMapNameOverride: my-config
extraFilesConfigMapChecksum: abc123

• The provided checksum is used
• DaemonSet annotation reflects this value
• Pods restart when checksum changes

When override is set but checksum is not:

• No checksum/config annotation is rendered
• No automatic rollout trigger is applied

Rationale

Helm charts typically rely on pod template annotations to trigger
rolling updates when configuration changes.

When using externally managed ConfigMaps, the chart cannot infer changes
automatically. This addition allows users to explicitly control rollout
behavior via a checksum value.

Backward compatibility

• No breaking changes
• Default behavior remains unchanged
• Existing users are unaffected

Testing

Verified with:

helm template . | grep checksum/config

and combinations of:

--set extraFilesConfigMapNameOverride=my-config
--set extraFilesConfigMapChecksum=abc123

Files changed

• charts/fluentd/templates/_helpers.tpl
• charts/fluentd/templates/daemonset.yaml
• charts/fluentd/values.yaml

[stevehipwell]

Why not just use podAnnotations (this would work correctly with no changes)? This change just adds to the API surface for no real benefit.

[elimayost]

I am subcharting, and therefore parent chart templates cannot inject dynamic values into the subchart's podAnnotations at render-time because subcharts are processed in a separate scope.

[stevehipwell]

I am subcharting, and therefore parent chart templates cannot inject dynamic values into the subchart's podAnnotations at render-time because subcharts are processed in a separate scope.

@elimayost I'm not sure I follow your argument or your use case given that sub-charts are part of a single context with the parent chart. Your PR adds extraFilesConfigMapChecksum but the calling convention for this is no different than setting podAnnotations."checksum/extraConfig".

[elimayost]

@stevehipwell That would work if I wanted to type the hash or annotation. But I want helm to calculate the hash.
In a parent-subchart relationship two things are not possible:

1. I can't put {{ .Files.Glob ... }} in values.yaml because it's a static YAML file.
2. If I create a template in my parent chart to calculate the hash and try to set it into the subchart's values, it's too late. Helm renders the subchart before it processes my parent templates. By the time my parent template calculates the hash, the subchart's DaemonSet has already been rendered with the old (or empty) values.

[stevehipwell]

@elimayost your PR only adds support for explicitly setting the annotation via a value, if extraFilesConfigMapChecksum is not set then the logic stays consistent.

I can't put {{ .Files.Glob ... }} in values.yaml because it's a static YAML file.

Correct, but why would you want to?

If I create a template in my parent chart to calculate the hash and try to set it into the subchart's values, it's too late. Helm renders the subchart before it processes my parent templates. By the time my parent template calculates the hash, the subchart's DaemonSet has already been rendered with the old (or empty) values.

This is incorrect, templates all operate at a global scope (it's why the names are <chart>.<function>).

If you want to provide some more details about how you're setting the configuration that may shed a bit more light on how this should be handled.

[elimayost]

@stevehipwell Sure. I subchart your chart. In my parent chart I have a config folder with various config files:

ls -lrth config/ total 80 -rw-r--r--@ 1 eli.mayost staff 1.7K 8 Apr 09:00 10_sources.conf -rw-r--r--@ 1 eli.mayost staff 257B 8 Apr 09:00 20_filter_fluent_loops.conf -rw-r--r--@ 1 eli.mayost staff 854B 8 Apr 09:00 22_parse_structured_logs.conf -rw-r--r--@ 1 eli.mayost staff 398B 8 Apr 09:00 24_add_cluster_labels.conf -rw-r--r--@ 1 eli.mayost staff 591B 8 Apr 09:00 26_add_kube_metadata.conf -rw-r--r--@ 1 eli.mayost staff 508B 8 Apr 09:00 28_filter_patterns.conf -rw-r--r--@ 1 eli.mayost staff 958B 8 Apr 09:00 29_add_default_logstream.conf -rw-r--r--@ 1 eli.mayost staff 369B 8 Apr 09:00 30_metrics.conf -rw-r--r--@ 1 eli.mayost staff 1.2K 8 Apr 09:00 40_outputs.conf -rw-r--r--@ 1 eli.mayost staff 377B 13 Apr 12:11 00_system.conf

In my values.yaml, fluentd.extraFilesConfigMapNameOverride: fluentd-future-conf, where fluentd-future-conf is:

cat templates/fluentd-future-conf.yaml apiVersion: v1 kind: ConfigMap metadata: name: fluentd-future-conf data: {{ tpl (.Files.Glob "config/*.conf").AsConfig . | indent 2 }}

I want to restart the pods every time a file changes in config directory.

Hope that explains the issue clearly.

[stevehipwell]

@elimayost this PR doesn't do anything for you if you're not passing in an explicit config hash, which you've said you're not doing. So I'm trying to understand the purpose of this PR?

The real fix for your use case is to add support for templating the values for the podAnnotations which would allow you to pass in your hash generation logic and have Helm run it for you.

      {{- range $k, $v := .Values.podAnnotations }}
        {{ printf "%s: %s" $k ((tpl $v $) | quote) }}
      {{- end }}

[elimayost]

@stevehipwell Makes sense. I've made a mess of this PR, so opened #709.
Thank you for your time.

[stevehipwell]

@elimayost I'll close this out then.