hashicorp / terraform-provider-helm

Terraform Helm provider
https://www.terraform.io/docs/providers/helm/
Mozilla Public License 2.0
997 stars 368 forks source link

Helm provider does not trigger an update, if local templates change #821

Open markusheiden opened 2 years ago

markusheiden commented 2 years ago

Terraform version, Kubernetes provider version and Kubernetes version

Terraform version: 1.1.3
Helm Provider version: 2.4.1
Kubernetes version: 1.20

Terraform configuration

resource "helm_release" "myapp" {
  namespace = "namespace"
  name      = "myapp"
  chart     = "${path.module}"
}

Question

Why does the Helm provider NOT trigger an update, if the files in the "templates" directory change? 
How to achieve that?

My temporary solution is to compute a hash of the templates files and use that as a dummy value.
resource "helm_release" "myapp" {
  ...

  // Trigger updates on template changes.
  set {
    name = "templatesHash"
    value = module.templates_hash.hash
  }
}

module "templates_hash" {
  source = "../helm-hash"
  chart_directory = path.module
}

helm-hash module:

variable "chart_directory" {
  description = "Chart directory"
  type        = string
}

locals {
  templates_directory = "${var.chart_directory}/templates"
  template_hashes     = {
  for path in sort(fileset(local.templates_directory, "**")) :
  path => filebase64sha512("${local.templates_directory}/${path}")
  }
  hash                = base64sha512(jsonencode(local.template_hashes))
}

output "hash" {
  value = local.hash
}
junzebao commented 2 years ago

We noticed the same issue. What we do is to bump the chart version every time there's a change in the templates. That'll trigger a helm upgrade.

markusheiden commented 2 years ago

I am aware of that, but the risk of not updating changed parts due to a forgotten version increase is not acceptable for me. It would be nice if a solution similar to my hack would make it into the provider.

vikaskoppineedi commented 2 years ago

I am facing the same issue, I am planning to add triggers with timestamp to overcome this issue, but this will cause the deployment to trigger everytime

beepdot commented 1 year ago

We noticed the same issue. What we do is to bump the chart version every time there's a change in the templates. That'll trigger a helm upgrade.

Thanks @junzebao. It works well and also is something very logical to do - just bump the chart version on chart changes

Oliniusz commented 1 year ago

For me, bumping the chart version by hand sounds like: we've automated everything, we just need to trigger the automation by hand each time

I'm looking for a solution that will trigger helm_release by any changes done under the postrender block and I think the checksum is the only way I know of at the moment. I calculate the changes in a directory and use it to change the description:

resource "helm_release" "istio-ingressgateway-internal" {
  name        = "istio-ingressgateway-internal"
  repository  = "https://istio-release.storage.googleapis.com/charts"
  chart       = "gateway"
  version     = "1.17.2"
  description = sha1(join("", [for f in sort(fileset("${path.module}/helm-values/istio-ingressgateway-internal-kustomize", "*")) : filesha1("${path.module}/helm-values/istio-ingressgateway-internal-kustomize/${f}")]))
  namespace   = kubernetes_namespace.istio-ingress.metadata[0].name
  timeout     = "900"
  values = [
    templatefile("${path.module}/helm-values/istio-ingressgateway-internal.yaml", { infra_name = var.infra_name, eks_suffix = var.eks_suffix })
  ]
  postrender {
    binary_path = "${path.module}/helm-values/istio-ingressgateway-internal-kustomize/kustomize.sh"
  }
  depends_on = [
    helm_release.istio-istiod,
    kubernetes_namespace.istio-ingress
  ]
}
djmcgreal-cc commented 9 months ago

I'm surprised this hasn't had more attention! Is there an explanation somewhere why this can't happen? It's really counterintuitive, and so even with work-arounds, new helm charts created aren't always spotted as requiring extra work to force a deployment.

helm template | kubectl diff -f - seems fairly straightforward, though I guess it'd need to filter hooks.

PowerSurj commented 6 months ago

description field changes cause provider errors i'm on terraform v1.6.4

Error: Provider produced inconsistent final plan
When expanding the plan for helm_release.myapp[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/helm" produced an invalid new value for .description: was cty.StringVal("4906e97bd629cbf998cd33647ab879d8ef90536e"), but now cty.StringVal("5380c9793e0f8669c17f5e45ee25ab927fe9bb28").

This is a bug in the provider, which should be reported in the provider's own issue tracker.
alfechner commented 6 months ago

We set reset_values = true and that works fine for us.

My understanding is that the default behaviour of Helm is to consider this flag true if it's not set. That's the behaviour we're all used to.

The Terraform helm_release resource however defaults to false. That explains the unusual behaviour I guess.

PowerSurj commented 6 months ago

The cause of error seems to have been coming due to the Chart with dependencies. Description driven updates work fine without reset_values and with Charts that have no dependencies. My solution is to break the dependencies into independent charts.

air3ijai commented 6 months ago

The cause of error seems to have been coming due to the Chart with dependencies.

I have a local-only chart without any dependencies. When I'm modifying a template in a local folder, Terraform does not detect any changes.

alfechner commented 6 months ago

@PowerSurj what's the issue with using reset_values?

lipika-pal-partior commented 6 months ago

@PowerSurj what's the issue with using reset_values?

reset_values will reset the values to the default ones built into the chart... so if you wish to use custom values it will be over-written

alfechner commented 5 months ago

@lipika-pal-partior you refer to set, set_list and set_sensitive, right?

I wasn't aware of those arguments, thanks for pointing me into that direction.

But wouldn't the custom values are applied back the moment terraform is applied? So the reset_values would reset them and then they would be added back?

djmcgreal-cc commented 5 months ago

reset_values doesn't work if the post_renderer executable changes. This really needs a more robust solution.

oubaydos commented 3 months ago

any updates ? I personally use this workaround

set {
    name  = "ignoreMe"
    value = timestamp()
  }

to trigger the deployment each time and let helm control which templates/values have changed

hubertlepicki commented 2 weeks ago

FYI, this is related to chart version. When you modify the chart/templates, edit Chart.yaml and bump up the version variable so that the changes get picked up and applied by Terraform.