How can we force a rollout when variable substitution changes?

[ulrichwinter]

We are using kustomize config map generators.
If the content of the configmap changes, kustomize produces a new suffix which then forces a rollout of the deployments.

But by adding flux variable substitution as a postbuild, we observ, that when the substituted variable value changes, the above mechanism does not apply, because kustomize is not triggered to produce a new suffix.
In fact, from a kustomize perspective, the CM always contains just the variable reference.

Is there any solution to make kustomize aware of the substituted variable value to produce a changed configmap suffix?

I've checked other discussions like #3611 but I can't see they are dealing with the same problem.

If the above behaviour is not possible, what are the patterns in use to trigger a new rollout using kustomize in case only a value substituted by a flux postBuild has changed?

[mathieu-letribot]

Hello,

I am dealing with the same issue, any solutions for that ?

[matheuscscp]

We have just implemented a feature for solving this problem that will be released in Flux 2.7. You can find it here:

#5446 (comment)

[mathieu-letribot]

Indeed, this feature is triggering a new reconciliation if a ConfigMap referenced on the Kustomization has changed.
But our problem is different I think. Let me provide an example.

We have a Kustomization that is deploying an app:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp
  namespace: default
spec:
  interval: 10m0s
  sourceRef:
    kind: GitRepository
    name: flux-system
    namespace: flux-system
  path: path/to/myapp
  prune: true
  force: true
  wait: true
  postBuild:
    substituteFrom:
      - kind: ConfigMap
        name: myConfigMap

Somewhere in path/to/myapp, we create a ConfigMap:

generatorOptions:
  annotations:
    kustomize.toolkit.fluxcd.io/prune: disabled
configMapGenerator:
  - name: my-app-configmap
    files:
      - my-app.conf

This ConfigMap is then referenced in multiple deployments.

What we observed is that, when we change a variable (referenced in the substituteFrom ConfigMap of the parent Kustomization), it is well updating the value of my-app-configmap (which is referencing this variable). But the problem is that the suffix remains the same. Which means, that we can reconciliate as much as we want, flux will won't notice that the ConfigMap has been updated, so it won't mount the new ConfigMap to the pods.

Maybe I'm wrong, or maybe I misunderstood how to use that watch feature.
What we would need, I think, is that the postBuild.substituteFrom generates a new suffix when ConfigMap has changed.