terraform-provider-helm icon indicating copy to clipboard operation
terraform-provider-helm copied to clipboard

Provider does not create diff for local chart changes

Open mvn-srizzari opened this issue 4 years ago • 10 comments

Issue was reported here but the title is unclear and that issue was closed. Also a fix is suggested here, but seems to be stuck since the original issue was closed out.

Seeing this issue with helm3.

When keeping charts locally, changes to the template yaml files will not cause a diff when running terraform plan. I've worked around this by incrementing the local chart version or using taints.

Terraform v0.12.24

Provider Version

helm (hashicorp/helm) 1.2.1

Affected Resource(s)

  • helm_release

Expected Behavior

Diff should be created when a template changes

Actual Behavior

No diff was created

Steps to Reproduce

  1. Create a local chart with a template
  2. Create a helm release resource that utilizes the chart
  3. Run terraform apply to create the resource
  4. Update the template yaml
  5. run terraform plan or terraform apply and see no diff is created.

References

  • https://github.com/terraform-providers/terraform-provider-helm/issues/346
  • https://github.com/terraform-providers/terraform-provider-helm/pull/357

mvn-srizzari avatar Jun 01 '20 22:06 mvn-srizzari

As described on the helm documentation (I read it but I couldn't find it, right now) a the release version should be increased every time a change happened on it, at least if you want to redeploy it. Are you upgrading the version?

mcuadros avatar Jun 01 '20 22:06 mcuadros

Updating the chart version is my "workaround" to get the tf diff, but from your comment that means it's expected behavior. I found it called out as a comment on this page: https://helm.sh/docs/topics/library_charts/.

It's a little at odds with how terraform works in that any change in tf almost always generates a diff, but you've shown this isn't a bug in the provider. Thanks for your quick response!

mvn-srizzari avatar Jun 02 '20 13:06 mvn-srizzari

Oh! Great you found it, I was searching for it several minutes, and I knew it, I read it!

This version number should be incremented each time you make changes to the chart and its templates, including the app version.

So yes, this is the expected behavior this doesn't mean that is odd. What I expect is that if I change a line in the chart should be updated. I agree, actually, I have a workaround in my code base that add as fake hash value to the release with an md5 of the chart folder.

The idea behind #357, is perfectly valid, the problem is that lacks the acceptance test, usually the hardest part to do in a chart, I will try to allocate some time to fix this.

mcuadros avatar Jun 02 '20 13:06 mcuadros

This version number should be incremented each time you make changes to the chart and its templates, including the app version.

I am not sure, but this advise seems rather to apply in cases where the chart is actually released to some repository, where others would reference it by name and version. In cases where one simply keeps the chart locally and deploys it, I think it produces a strange development experience, especially when compared how other terraform resources are handled and that the resource is already versioned when it is part of a terraform module. At least it took me some time to recognize this behavior and search for this issue here.

JarnoRFB avatar Nov 05 '20 07:11 JarnoRFB

I agree that this produces a strange/unpleasant developer experience when using local charts. Perhaps a force_deploy flag that would force helm upgrade could work?

carsondoesbusiness avatar Apr 02 '21 14:04 carsondoesbusiness

A colleague of mine came up with the idea to pass

resource "helm_release" "my_release" {
  values = [
    ...,
    yamlencode({
      dummy: uuid()
    })
  ]
}

This way the values are changed each time which leads to the helm release being always applied. We use this when we develop a terraform module that includes helm charts and later on increment the version of the module when we are happy with the changes.

Still this is a hack.

JarnoRFB avatar Apr 04 '21 19:04 JarnoRFB

Faced similar issues - had to fallback to @JarnoRFB hack

m00lecule avatar May 12 '22 00:05 m00lecule

@JarnoRFB's hack triggers an upgrade at every apply, not only when the local chart changes. Here is an upgrade to the hack that does not suffer from that drawback:

  1. Compute a hash of the chart's contents:
locals {
  chart_path = "./my-chart"
  # Terraform's helm provider does not detect diffs in a local chart.
  # Github issue: https://github.com/hashicorp/terraform-provider-helm/issues/515
  # Our workaround: add a dummy value containing a hash of the chart's contents.
  chart_hash = md5(join("", [
    for f in fileset(local.chart_path, "**") :
    filemd5(format("%s/%s", local.chart_path, f))
  ]))
}
  1. Add the hash to the release's values:
resource "helm_release" "example" {
  name      = "my-release"
  namespace = "my-namespace"
  chart     = local.chart_path

  values = [
    ...,
    yamlencode({
      chart_hash : local.chart_hash,
    })
  ]
}

busser avatar Sep 05 '22 17:09 busser

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

github-actions[bot] avatar Sep 06 '23 00:09 github-actions[bot]

not stale - the provider should be doing this md5 if at all possible on local charts

mmerickel avatar Sep 19 '23 20:09 mmerickel