Release resource not updated after manual change

[MisterMX]

What happened?

If a resource that is part of a release is edited manually (i.e. via kubectl edit), the controller does not update the release during the next reconcile. If the release is updated manually via helm upgrade the resource is changed.

The issue is most likely that provider-helm only compares the release manifests to determine if changes are necessary. This would be similar to helm diff plugin which does not detect any changes as well.

Is this intended behavior? If yes, is there some way to circumvent this?

How can we reproduce it?

1. Create a simple helm chart that deploys a single resource, i.e a ConfigMap and deploy it via a managed simple Release:

apiVersion: v1
kind: ConfigMap
metadata:
    name: {{ .Release.Name }}-config
data:
    hello: world

2. Edit the resource manually via kubectl edit.
3. Wait for the next reconcile which will not trigger an update. helm diff will not show any changes as well.

What environment did it happen in?

Provider version: v0.7.0

[RafalMaleska]

interested in this as well.

other crossplane providers (provider-aws) use a reconciliation loop that offer self-healing abilities. If one modifies a resource in the cloud manually (creating a state drift) provider-aws will make sure to divert this change. it would be more crossplane agnostic if provider-helm follows this principle.

moreover the reconcile goes along with gitops principles (state in git = state in the cluster = state of the helm release).

i'm aware that this is not always possible (ex. while using hpa) but would be definitely a useful feature to offer self healing abilities for helm charts.

[turkenh]

Thanks for the ticket! I totally see your point however there are some nuances and technical challenges that make it infeasible.

The interface that provider-helm interacts with the external resource (a helm release) is the helm client itself. As long as the desired spec (what is in release CR) matches with the observation (helm release information returned by helm client) matches, provider-helm considers this as synced. See the design doc for more details on that. I believe this better fits Crossplane model with representing remote helm release as the external resource to manage. Self-healing still works if you change the release with helm upgrade etc.

Still, templating was also something that we considered while designing but we didn't prefer that due to some gotchas.

[ron1]

@turkenh Do you know if/how the the flux v2 helm-controller solves this problem? I believe it also uses the helm sdk.

[bradonkanyid]

In my experience, no it does not. Flux helm-controller also uses the helm state as source-of-truth so out-of-band changes aren't self-healed.