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

Unspecified version is supposed to pick latest, but does so only for `helm_release` creation

Open Porkepix opened this issue 2 years ago • 2 comments

Note that this might be a known and wanted behavior, and as such be classified as a feature request rather than a bug.

Terraform, Provider, Kubernetes and Helm Versions

Terraform version: 1.2.4
Provider version: 2.6.0
Kubernetes version: 1.21 on EKS

Affected Resource(s)

  • helm_release

Terraform Configuration Files

resource "helm_release" "gitlab-runner" {
  name       = "gitlab-runner"
  repository = "https://charts.gitlab.io"
  chart      = "gitlab-runner"
  namespace  = "foo"
  values     = [data.template_file.gitlab-runners.rendered]

  depends_on = [kubernetes_namespace.gitlab-runners]
}

Steps to Reproduce

Just apply the above resource

Expected Behavior

Prior to that we specified the helm version release and had no issue there. After reading https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#version it appeared than if we didn't specify the version, it should pick the latest, and therefore upgrade to the latest release.

Actual Behavior

The actual behavior is that it picks the latest on resource creation, but not if the resource already exists and should be upgraded to a newer version. Here, we're on release 0.41 and 0.42 is available, but applying the terraform layer reports no change to do.

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

Porkepix avatar Jul 08 '22 16:07 Porkepix

Hello! Thank you for bring this issue up, this is by design. We would prefer that any version updates are done explicitly, so that users aren't surprised with a diff on later applies.

BBBmau avatar Jul 13 '22 16:07 BBBmau

Hello! Thank you for bring this issue up, this is by design. We would prefer that any version updates are done explicitly, so that users aren't surprised with a diff on later applies.

Then why allowing to not specify it for the first apply of the layer? Also, it might make sense to let user always get latest, even if it means forcing it by a way or another, the example I gave is an interesting one in that matter: we're GitLab customers but on their SaaS offer, not on premise. This means the server part will always use the latest version and we have can't decide anything about it. considering that, it's always better to have the runners to be synchronized and use the latest one too so that we're, if possible, on the same version as the server part.

Porkepix avatar Jul 13 '22 17:07 Porkepix

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