HelmChartConfig deletion is not tracked

[tallaxes]

It appears the controller is currently silently ignoring the deletion of HelmChartConfig resource. It seems the the controller should track those, and redeploy (upgrade?) the corresponding Helm release to reflect the new desired state. Since the controller does track updates, a workaround is to update the deployed HelmChartConfig resource to one with "empty" values. But properly tracking deletions would be better, as it would match the intuitive expectations / principle of least surprise.

[SchoolGuy]

Isn't this a duplicate of #33 ?

[tallaxes]

@SchoolGuy: No, it is not. #33 is not very precise about exactly what deletion is failing, but it is most likely about deletion of Helm releases via deletion of HelmChart resource. This one is about removing the customization / extra values via deletion of HelmChartConfig resource - and keeping / redeploying the release.

[ckyoog]

I am using k3s-v1.21.4+k3s1. Also running into this issue. Adding a HelmChartConfig results in my k8s resources getting updated, but nothing happens when deleting it.

Taking traefik as an example.
The following things would happen when I add a HelmChartConfig

• A Configmap in which all the Helm Values are stored is updated. The new values is appended into the Configmap. (It is chart-values-traefik in my example)
• The helm-install Job (which is helm-install-traefik in my example) is re-created. The helm-install is re-run against the updated Configmap.
• My k8s resources are updated expectedly.

When deleting the HelmChartConfig, nothing happens

• The Configmap is not updated
• The Job is not re-created
• Nothing gets updated

[tlandschoff-scale]

I can confirm this report. Just ran into this because I changed the traefik log level to debug. After fixing my problem I removed the HelmChartConfig again.

My expectation was the traefik would be upgraded with the old log level. Instead it kept running at log level debug.

[guillaumebernard84]

Hello, I had the problem today, and maybe I can add more info:
I wanted to move the content of the HelmChartConfig CRD to the "valuesContent" field of the HelmChart CRD, while doing some modification to the config.
So I deleted the HelmChartConfig CRD and updated the HelmChart CRD with a "valuesContent" field.

When I applied my modifications, the helm job did run, but the old values of the deleted HelmChartConfig were still used instead of the new ones from the HelmChart.

The problem comes from the "chart-values-xxx" secret which still contains the "values-10_HelmChartConfig.yaml" data, which contains the values from the deleted HelmChartConfig. These values take precedence over the "values-01_HelmChart.yaml" that exists in the same secret.

To workround the problem, I deleted the secret before removing the HelmChartConfig CRD

[brandond]

The ValuesSecret contents are regenerated every time the HelmChart or HelmChartConfig resource are modified:

helm-controller/pkg/controllers/chart/chart.go

Lines 590 to 618 in 2f32059

	func valuesSecret(chart *v1.HelmChart) *corev1.Secret {
	var secret = &corev1.Secret{
	TypeMeta: metav1.TypeMeta{
	APIVersion: "v1",
	Kind: "Secret",
	},
	ObjectMeta: metav1.ObjectMeta{
	Name: fmt.Sprintf("chart-values-%s", chart.Name),
	Namespace: chart.Namespace,
	},
	Type: corev1.SecretTypeOpaque,
	Data: map[string][]byte{},
	}
	if chart.Spec.ValuesContent != "" {
	secret.Data["values-01_HelmChart.yaml"] = []byte(chart.Spec.ValuesContent)
	}
	if chart.Spec.RepoCA != "" {
	secret.Data["ca-file.pem"] = []byte(chart.Spec.RepoCA)
	}
	return secret
	}
	func valuesSecretAddConfig(secret *corev1.Secret, config *v1.HelmChartConfig) {
	if config.Spec.ValuesContent != "" {
	secret.Data["values-10_HelmChartConfig.yaml"] = []byte(config.Spec.ValuesContent)
	}
	}

If the HelmChartConfig is deleted, the relevant section will be absent from the generated secret. I don't see any way that the values-10_HelmChartConfig.yaml would continue to be present if the source for that content is gone.

[guillaumebernard84]

Hello, you are right, I'm not able to reproduce the problem.

I ran into this problem when I used terraform to update a lot of helmcharts and delete a lot of helmchartconfigs (using fleet) AND upgrade RKE2 (using rancher) from 1.27 to 1.28 at the same time. Maybe this caused the problem as RKE2 is restarted several times in the process? I was able to reproduce it several times while testing the upgrade.

If I only update the helmcharts and delete the helmchartconfigs after the upgrade to 1.28 is completed, I don't encounter the problem.

Thank you