Providing values from ConfigMap and Secret resources about helm-controller

[nvanheuverzwijn]

Something got me really confused with the optional flag. I though that optional was saying that if the values was not found, either the Secret/ConfigMap object OR the valuesKey in the Secret/ConfigMap, it didn't matter.
After some testing, I understand that optional is really only saying that if the Secret or ConfigMap does not exist we don't care but if it does exist, you better have that valuesKey defined in those Secret/ConfigMap otherwise, reconciliation will fail.

That feels counterintuitive. If the valuesFrom is really optionnal, reconcilliation should be successful even if the valuesKey does not exist.

Any though ?

[stealthybox]

This choice was made because you can not reliably restore the cluster state from Git repositories if the configuration of a service relies on some URL being available.

We could document a workaround for migration.
A user could create a CronJob in the same namespace that curls a URL into a ConfigMap using a config-editor ServiceAccount.

The HelmRelease may then depend on that.

The CronJob can choose what to do when the URL becomes unavailable which allows the user to decide how the error should be handled separately from whether the valueRef's is optional.

[stealthybox]

having the optional param ...

Do we already support optional vs. required valueRefs?

I don't see it in the current API.
I was thinking we could basically take the same optional field from Pod's ConfigMapEnvSource

It should be noted that even if we are no longer supporting URL's, ConfigMap/Secrets's with values may often not come from the same gitRepo or even a gitRepo at all.
They may come from another gitRepo, be placed in the cluster manually (example above), or be the result of some other controller (ex: cert-manager).

Should we support explicitly optional valueRefs?

[stealthybox]

optional valueRefs would allow helmReleases to change config based on the live state of the cluster.
This could be useful for allowing a users to extend behavior at a later date with their own repo without modifying the HelmRelease object.
As long as the user can create/modify the referenced Configs, they can turn on/off features and etc.
This works kind of like a UNIX style /config.d/ dir.

I do a similar thing with volumes:
I like to modify my CoreDNS config so that adding keys to a separate coredns-corefile-extras ConfigMap ends up appending to the config from other repos.
This is done through an optional volumeMount for /etc/corefiles.d/.

[Skarlso]

@stealthybox Hello! I would like to offer my help if I can on getting the watch working on the respective resources?

[XtremeAI]

Hi guys! Not sure where this Watching feature is but when values in ConfigMaps or Secrets change there goes no release upgrades and I have not found anything better rather than do flux delete hr <name> to apply the changes which isn't the desired way of course.

[yebyen]

If you're using valuesFrom with a secret ref or configmap the flux reconcile hr command should pick up the changes, or automatically be picked up on the next reconciling event. @XtremeAI is that not the case?

If so you should provide specific reproduction instructions as you may have found a new bug, that is not the subject of this issue report. The watching functionality is only meant to accelerate this behavior, it should be happening on its own if you are patient or if you manually trigger the HelmRelease reconciling.

Please be very specific as this functionality seems to be working for me and so you may have to describe the particular conditions that led to an edge case which I am not naturally going to find on my own.

(Edit: apologies as I may have this confused with another issue report, some of the details don't seem to match the issue I thought I was commenting on.)

[XtremeAI]

Hi @yebyen . Thanks for response. I went and did a bit more research and reconciliation does go ahead which kicks the helm upgrade of the chart. Therefore the issue I am having that pods that rely on new config maps are not getting restarted are probably related to helm upgrade not the HelmRelease controller... so I will dig in that direction I guess ...
(upd) OK, found the root cause: https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments

[kingdonb]

Awesome

I think the recreate-pods is only supported through rollback spec in Helm Controller. That root cause link you mentioned @XtremeAI is perfect, you can enforce the pods recreation through use of an annotation that changes based on the shasum of the configmap. Then you also get the benefit of only recreating pods when the configmap has actually changed under it!

[wyndigo-01]

Before I create a new feature request. helm-operator allowed you to specify the source namespace for configmaps and secrets that were used in the valuesFrom. This was very useful, and I'm wondering if there is a specific reason that functionality was removed?

[hiddeco]

See https://fluxcd.io/flux/migration/helm-operator-migration/#values-from-configmap-and-secret-resources-in-other-namespaces-are-no-longer-supported