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

Bug - helm_release mixing values and set arguments and ignoring values changes will revert the values on apply

Open j-martin opened this issue 4 years ago • 6 comments

Terraform Version and Provider Version

Terraform v0.12.23

  • provider.external v1.2.0
  • provider.google v3.12.0
  • provider.google-beta v3.12.0
  • provider.helm v1.2.2
  • provider.kubernetes v1.10.0
  • provider.null v2.1.2
  • provider.vault v2.5.0

Provider Version

1.2.2

Affected Resource(s)

  • helm_release

Terraform Configuration Files

resource "helm_release" "app" {
  for_each = var.sub_environments

  chart           = local.app_chart
  name            = each.key
  namespace       = each.key
  timeout         = 45 * 60 # seconds, loading the initial backup will take a while.
  cleanup_on_fail = true
  atomic          = true

  set {
    name  = "isProduction"
    value = var.is_production
  }

  set {
    name  = "domain"
    value = trimsuffix(google_dns_record_set.app[each.key].name, ".")
  }

  dynamic "set" {
    for_each = var.sub_environments[each.key]
    content {
      name  = set.key
      value = set.value
    }
  }

  values = compact([
    data.external.app_version[each.key].result.yaml,
  ])

  depends_on = [
    module.k8s_db_service_account,
    module.k8s_serviceA_service_account,
    helm_release.app_shared,
    kubernetes_namespace.app,
  ]

  provider = helm.primary
}

data "external" "app_version" {
  for_each = toset(keys(var.sub_environments))
  working_dir = abspath("../../../")
  program = [
    "python3.7",
    "-m", "utils.helm_get_current_or_latest_version",
    "--project", module.gke_cluster_primary.cluster.project,
    "--region", module.gke_cluster_primary.cluster.location,
    "--cluster-name", module.gke_cluster_primary.cluster.name,
    "--release-name", each.key,
    "--json-wrapper"
  ]
}

Debug Output

Expected Behavior

We would at least expect that the current value passed to the values arguments would be used instead of the ones in the existing state.

Actual Behavior

Once the plan has been applied, the values of release are now the old values that were in the state combined with the new values set by the terraform config. This is effectively a rollback of our services.

Steps to Reproduce

  1. Define the versions with the values helm_release argument and some other properties with set argument.
  2. Enable lifecycle {ignore_changes = [values]} on the helm_resource.
  3. Change the value property.
  4. Run terraform plan to see it being ignored.
  5. Change a value set by the set argument in helm_release.
  6. Run terraform apply.

Important Factoids

We currently use the terraform-provider-helm to set up our production, staging, UATs, etc. with an helm_release. It setups some resources like bootstrapping service account with GKE Workload Identity, specify some values like external resources to the cluster (e.g. db, some caches, etc.).

We then do deployments outside of terraform, directly via helm where we change the value versions of some services. To avoid terraform updating for no reason, we also have a small script that checks the current version of services from the current helm release values currently deploy that populates the values helm_release arguments.

Our values.yaml chart file look something like this:

---
environment: staging

serviceA:
  version: 20200605-031242-6a98615

serviceB:
  version: 20200605-031242-6a98615

Note that the issue may span from Terraform itself. I am not sure. I just never observed the behavior before it might come from the fact the only the previous terraform state is used to decide if an update is required or not https://github.com/hashicorp/terraform-provider-helm/issues/523

References

  • GH-1234

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

j-martin avatar Jun 05 '20 18:06 j-martin

@j-martin

We suspect this issue is now resolved. If you are still running into this issue, please let us know so that we can prioritize and investigate further, if this problem no longer exists please confirm and close this issue. Thanks!

iBrandyJackson avatar Nov 29 '21 23:11 iBrandyJackson

Hello, We are facing the same issue with 2.5.1. We also mix set and values and changing values has sometimes no effect, sometimes being it worked a few times until we changed both set and values properties.

github-vincent-miszczak avatar Jul 12 '22 08:07 github-vincent-miszczak

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 Jul 13 '23 00:07 github-actions[bot]

Still relevant.

robin-wayve avatar Jul 13 '23 07:07 robin-wayve

this is still happening to me on helm provider 2.10.1 + [email protected]

I'm using values and multiple sets and I've verified that helm release contained the right values (applied all values files and sets), and I've verified that the tfstate file contained the right values.

the severity of this issue is the plan output missed the set change (for me).

duxing avatar Aug 26 '23 10:08 duxing