Watch for ConfigMaps and Secrets values changes to trigger a sync

[sa-spag]

Today, the Helm operator does not trigger an upgrade as soon as a ConfigMap or Secret referenced using HelmRelease .spec.valuesFrom changes. It would be nice not to have to wait for the next periodic sync to have the release updated.

Given I have a HelmRelease that refers ConfigMaps or Secrets through .spec.valuesFrom When one of these ConfigMaps or Secrets changes Then the operator triggers a release upgrade

[seaneagan]

On the other hand, if there are multiple changes, e.g. a ConfigMap, Secret, and HelmRelease, wouldn't this lead to multiple quick fire new release revisions, as the operator reacts to each change, which seems undesirable?

[robertverusen]

The need for "debouncing" is a good point, but without this, how is one intended to signal to helm-operator that a new release is needed after changing a ConfigMap used with valuesFrom?

I was hoping that using kustomize, I could depend on the hash-appending feature of the configMapGenerator, but kustomize doesn't seem to know how to rewrite ConfigMap names inside a HelmRelease. Without that, I'm forced to manually change the ConfigMap name for each new update.

Eventually I just gave up on using valuesFrom and inlined the values in the HelmRelease. That makes it a little harder to work with complex charts like prometheus-operator, when I want to run helm template to see what will eventually be deployed. Not the end of the world.

[mrtndwrd]

This is an important issue for me as well!

Is there a workaround to trigger the helm-operator when I adjust a valuesFrom related secret?

To be honest I think I would be willing to accept that multiple changes can lead to multiple releases if debouncing is not an option.

[varac]

Is there a workaround to trigger the helm-operator when I adjust a valuesFrom related secret?

I requested excatly this feature in #467

[kingdonb]

Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller.

A new release of Helm Operator is out this week, 1.4.4.

We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository.

Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2.

In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo.

Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved.

We recommend upgrading to Flux v2 which is actively maintained ASAP.

I am going to go ahead and close every issue at once today, Thanks for participating in Helm Operator and Flux! 💚 💙