metadata always recomputes, causing redeployment for every single plan-apply

[meysam81]

Terraform, Provider, Kubernetes and Helm Versions

Terraform version: v1.7.3
Provider version: v2.12.1
Kubernetes version: v1.29.2+k3s1

Affected Resource(s)

• helm_release

Terraform Configuration Files

terraform {
  required_providers {
    helm = {
      source  = "hashicorp/helm"
      version = "2.12.1"
    }
  }
}

provider "helm" {
  kubernetes {
    config_path = "~/.kube/config"
  }
}

resource "helm_release" "this" {
  name             = "redis"
  repository       = "https://charts.bitnami.com/bitnami"
  chart            = "redis"
  namespace        = "cache"
  create_namespace = false
  version          = "19.x"
}

Debug Output

https://gist.github.com/meysam81/8b4c8805d7dcfa7dd116443c4cc42841

NOTE: In addition to Terraform debugging, please set HELM_DEBUG=1 to enable debugging info from helm.

Panic Output

Steps to Reproduce

Either of the following:

• terraform apply
• terraform plan -out tfplan && terraform apply tfplan

Expected Behavior

Even in the case where the latest chart version is the same as the running helm-release, it is still updating the metadata and trying to re-deploy the release. A frustrating experience really. Ansible helm module is doing a much better job in this regards when it comes to idempotency.

The funny thing is, if you pin the version to exact version, e.g. 19.0.1, this won't happen and a No changes will be printed on the screen. But any version wildcard versioning causes the release to recompute the metadata. 🤷

Actual Behavior

It finds metadata changed for every single plan-apply.

Important Factoids

Nothing special. I have tried this in different clusters with different versions. All have the same outcome.

References

• Always recompute metadata when a release is updated #1097
• GH-1097 causes metadata to always be recomputed with some helm charts. #1150

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[sheneska]

Hi @meysam81, thanks for opening this issue.
I was able to reproduce this and found it was a bug. It looks like we will need to add support for wildcard versions in the custom diff here:

terraform-provider-helm/helm/resource_release.go

Lines 845 to 857 in d533734

	if !useChartVersion(d.Get("chart").(string), d.Get("repository").(string)) {
	if d.HasChange("version") {
	// only recompute metadata if the version actually changes
	// chart versioning is not consistent and some will add
	// a `v` prefix to the chart version after installation
	old, new := d.GetChange("version")
	oldVersion := strings.TrimPrefix(old.(string), "v")
	newVersion := strings.TrimPrefix(new.(string), "v")
	if oldVersion != newVersion && newVersion != "" {
	d.SetNewComputed("metadata")
	}
	}
	}

.

[sheneska]

For now the workaround would be to specify the exact version.

[chotiwat]

Hi @sheneska, I ran into this issue as well and have submitted a potential fix based on your finding here #1458.

[meysam81]

I confirm that v1.16.0 has fixed the metadata change, specifically and in my use case, the wildcard versioning of the helm release is resulting in a correct behavior.

Here's a minimal working example (applying this stack twice won't show changes on metadata anymore):

terraform {
  required_providers {
    helm = {
      source  = "hashicorp/helm"
      version = "2.16.0"
    }
  }
}

provider "helm" {
  kubernetes {
    config_path = "~/.kube/config"
  }
}

resource "helm_release" "this" {
  name             = "redis"
  repository       = "https://charts.bitnami.com/bitnami"
  chart            = "redis"
  namespace        = "default"
  create_namespace = false
  version          = "20.x"
}