Changes to a single set{} block causes all blocks to appear in the terraform plan output

[ksvladimir]

Terraform Version and Provider Version

Terraform v0.13.5 and v0.14.0-rc1

Provider Version

v1.3.2

Affected Resource(s)

• helm_release

Terraform Configuration Files

resource "helm_release" "example" {
  name       = "my-redis-release"
  repository = "https://charts.bitnami.com/bitnami"
  chart      = "redis"
  version    = "12.0.1"

  set {
    name  = "cluster.enabled"
    value = "true"  # <<< CHANGE HERE
  }

  set {
    name  = "metrics.enabled"
    value = "true"
  }

  set {
    name  = "service.annotations.prometheus\\.io/port"
    value = "9127"
  }
}

Steps to Reproduce

1. terraform apply
2. change true to false next to "<<< CHANGE HERE" above
3. terraform plan

Expected Behavior

I expect to see that only one set block has changed.

Actual Behavior

Terraform plan shows all set blocks being removed and added:

      + set {
          + name  = "cluster.enabled"
          + value = "false"
        }
      - set {
          - name  = "cluster.enabled" -> null
          - value = "true" -> null
        }
      - set {
          - name  = "metrics.enabled" -> null
          - value = "true" -> null
        }
      + set {
          + name  = "metrics.enabled"
          + value = "true"
        }
      - set {
          - name  = "service.annotations.prometheus\\.io/port" -> null
          - value = "9127" -> null
        }
      + set {
          + name  = "service.annotations.prometheus\\.io/port"
          + value = "9127"
        }

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

[psr-tv2]

Seeing the same issue.

[tculp]

This is still an issue present in the latest version

[github-actions[bot]]

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!

[pawelpesz]

This is still a problem. And a significant one, IMHO.

[TheQueenIsDead]

This provider has been super (for me) ever since the duplicate ticket was resolved by the v2.8.0 release.

For those of you still encountering issues, it would be worth specifying your versions and config, as the following example code and versions worked nicely for me:

Versions

$ terraform version
Terraform v1.4.2
on linux_amd64
+ provider registry.terraform.io/hashicorp/helm v2.9.0

Config

resource "helm_release" "example" {
  name       = "my-release"
  repository = "https://charts.bitnami.com/bitnami"
  chart      = "redis"
  version    = "17.9.2"

  set {
    name  = "cluster.enabled"
    value = "true"  # <<< CHANGE HERE
  }

  set {
    name  = "metrics.enabled"
    value = "true"
  }

  set {
    name  = "service.annotations.prometheus\\.io/port"
    value = "9127"
  }
}

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

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

The resultant diff was like so

$ tf plan
helm_release.example: Refreshing state... [id=my-release]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # helm_release.example will be updated in-place
  ~ resource "helm_release" "example" {
        id                         = "my-release"
        name                       = "my-release"
        # (27 unchanged attributes hidden)

      - set {
          - name  = "cluster.enabled" -> null
          - value = "true" -> null
        }
      + set {
          + name  = "cluster.enabled"
          + value = "false"
        }

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

While it could be more concise (Showing a singular set { value = "*" } change), only showing the changed set blocks instead of ones that had no change has made this plugin much more usable, solving this issue

[pawelpesz]

only showing the changed set blocks instead of ones that had no change has made this plugin much more usable, solving this issue

Exactly, that would be the expected behaviour. Thanks @TheQueenIsDead 👍

[TheQueenIsDead]

@pawelpesz , that is not simply the expected behavior, that is the current behavior as of this morning

[pawelpesz]

@TheQueenIsDead sorry, I misquoted your comment. I would expect a more concise plan, instead of:

# helm_release.example will be updated in-place
~ resource "helm_release" "example" {
      id                         = "my-release"
      name                       = "my-release"
      # (27 unchanged attributes hidden)

    - set {
        - name  = "cluster.enabled" -> null
        - value = "true" -> null
      }
    + set {
        + name  = "cluster.enabled"
        + value = "false"
      }

      # (1 unchanged block hidden)
  }

something like this:

# helm_release.example will be updated in-place
~ resource "helm_release" "example" {
      id                         = "my-release"
      name                       = "my-release"
      # (27 unchanged attributes hidden)

    ~ set {
        name  = "cluster.enabled"
        ~ value = "true" -> "false"
      }

      # (1 unchanged block hidden)
  }

Obviously the current behaviour is much better then before v2.8.0 but still, I do think this is still worth taking care of 😄

[github-actions[bot]]

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!