Upgrade v2.2.1 -> v3.4.0 forces replacement

[blgm]

Terraform CLI and Provider Versions

Terraform v1.2.8
on darwin_amd64

• provider registry.terraform.io/hashicorp/random v3.4.0

Terraform Configuration

terraform {
  required_providers {
    random = {
      source = "hashicorp/random"
#      version = "3.3.2"
      version = "3.4.0"
#      version = "2.2.1"
    }
  }
}

resource "random_password" "password" {
  length           = 31
  override_special = "~_-."
  min_upper        = 2
  min_lower        = 2
  min_special      = 2
}

Expected Behavior

When a password was created with v2.2.1, I expect to be able to upgrade to v3.4.0 and for there to be no changes to the password.

Actual Behavior

When a password was created with v2.2.1, when I upgrade to v3.4.0 the password is replaced:

random_password.password: Refreshing state... [id=none]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # random_password.password must be replaced
-/+ resource "random_password" "password" {
      ~ bcrypt_hash      = (sensitive value)
      ~ id               = "none" -> (known after apply)
      ~ min_upper        = 0 -> 2 # forces replacement
      ~ result           = (sensitive value)
        # (10 unchanged attributes hidden)
    }

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

Steps to Reproduce

1. With provider v2.2.1, do terraform init, terraform apply
2. Change to provider v3.4.0, do terraform init -upgrade, terraform apply

Note that going from v2.2.1 to v3.3.2 does not force replacement of the password. If I then update to v3.4.0 then the password is still not replaced. The password is only replaced with a jump upgrade straight from v2.2.1 to v3.4.0

If it's just impossible to support this jump upgrade then that's ok, but it would be ideal if this did work.

How much impact is this issue causing?

Medium

Logs

https://gist.github.com/blgm/e6f41c1209d1394a986344324bebc4ef

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[alexpoto]

Note that going from v2.2.1 to v3.3.2 does not force replacement of the password. If I then update to v3.4.0 then the password is still not replaced. The password is only replaced with a jump upgrade straight from v2.2.1 to v3.4.0

have same issue after upgrade 3.3.2 -> 3.4.0

upd.

but we have it like this:

resource "random_password" "some-pass" {
  length = 16
  special = true
  lifecycle { ignore_changes = [keepers, length, lower, min_lower, min_numeric, min_special, min_upper, number, numeric, special, upper] }
}

[bflad]

Hi folks 👋 If you could continue to show your resource configurations and the plan outputs where this is occurring, that would be immensely helpful to ensure we capture all the issues.

For configurations using ignore_changes, if the configuration for the attribute showing the plan difference is not actually present, removing that attribute from ignore_changes may help in the meantime.

For example switching the last comment configuration from:

resource "random_password" "some-pass" {
  length = 16
  special = true
  lifecycle { ignore_changes = [keepers, length, lower, min_lower, min_numeric, min_special, min_upper, number, numeric, special, upper] }
}

To:

resource "random_password" "some-pass" {
  length = 16
  special = true
  lifecycle { ignore_changes = [length, special] }
}

Please let reach out if it does/doesn't.

[alexpoto]

Please let reach out if it does/doesn't.

tried

resource "random_password" "database-user-revenues-admin-password" {
  length = 16
  special = true
  # lifecycle { ignore_changes = [keepers, length, lower, min_lower, min_numeric, min_special, min_upper, number, numeric, special, upper] }
  lifecycle { ignore_changes = [length, special] }
}

no difference with previous tries:

  # random_password.database-user-revenues-admin-password must be replaced
-/+ resource "random_password" "database-user-revenues-admin-password" {
      ~ bcrypt_hash      = (sensitive value)
      ~ id               = "none" -> (known after apply)
      - keepers          = {} -> null # forces replacement
      + length           = 16
      + lower            = true # forces replacement
      + min_lower        = 0 # forces replacement
      + min_numeric      = 0 # forces replacement
      + min_special      = 0 # forces replacement
      + min_upper        = 0 # forces replacement
      + number           = true # forces replacement
      + numeric          = true # forces replacement
      + override_special = (known after apply)
      ~ result           = (sensitive value)
      + special          = true # forces replacement
      + upper            = true # forces replacement
    }

[lra]

Same issue for us, here's a reproducible example of a random_password resource replacement due to the upgrade from v3.3.2 to v3.4.0:

Prior to upgrade:

Terraform v1.2.8
on darwin_arm64
+ provider registry.terraform.io/hashicorp/random v3.3.2

resource "random_password" "prod_az_eastus_raptor_pg_ns" {
  length = 20
}

$ terraform plan
No changes. Your infrastructure matches the configuration.

$ terraform state show random_password.prod_az_eastasia_bison_pg_ns
# random_password.prod_az_eastasia_bison_pg_ns:
resource "random_password" "prod_az_eastasia_bison_pg_ns" {
    bcrypt_hash = (sensitive value)
    id          = "none"
    result      = (sensitive value)
}

Post upgrade to 3.4.0:

Terraform v1.2.8
on darwin_arm64
+ provider registry.terraform.io/hashicorp/random v3.4.0

$ terraform plan

Terraform will perform the following actions:

  # random_password.prod_az_eastasia_bison_pg_ns must be replaced
-/+ resource "random_password" "prod_az_eastasia_bison_pg_ns" {
      ~ bcrypt_hash      = (sensitive value)
      ~ id               = "none" -> (known after apply)
      + length           = 16
      + lower            = true # forces replacement
      + min_lower        = 0 # forces replacement
      + min_numeric      = 0 # forces replacement
      + min_special      = 0 # forces replacement
      + min_upper        = 0 # forces replacement
      + number           = true # forces replacement
      + numeric          = true # forces replacement
      + override_special = (known after apply)
      ~ result           = (sensitive value)
      + special          = true # forces replacement
      + upper            = true # forces replacement
    }

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

We have plenty of other occurrences by I guess they are all due to the same reasons.

The problem still occurs with v3.4.1

[scott-doyland-burrows]

We have similar issues.

The following was working fine on provider 3.3.2.

I just ran a plan using provider 3.4.2 and it wants to force a replace. min_special used to default to null (I can see this in the statefile).

Now on the later provider it defaults to 0 and so terraform considers this a change.

resource "random_password" "pwapi_primary" {
  length      = 32
  min_lower   = 10
  min_numeric = 12
  min_upper   = 10
  special     = false
}

  # random_password.pwapi_primary must be replaced
-/+ resource "random_password" "pwapi_primary" {
      ~ bcrypt_hash = (sensitive value)
      ~ id          = "none" -> (known after apply)
      + min_special = 0 # forces replacement
      ~ result      = (sensitive value)
        # (9 unchanged attributes hidden)
    }

I have now pinned to the old provider.

My other option is to manually fix the statefile I suppose.

This is effectively a breaking change - so shouldn't it at least have been a major version bump?

[bendbennett]

Hi @scott-doyland-burrows thank you for supplying the configuration and Terraform CLI output.

I'm unable to reproduce with this configuration:

resource "random_password" "pwapi_primary" {
  length      = 32
  min_lower   = 10
  min_numeric = 12
  min_upper   = 10
  special     = false
}

By first applying it with 3.3.2 then again with 3.4.2.

I see the same issue as described in random_password Showing Unexpected Plan 3.3.2 to 3.4.2

[scott-doyland-burrows]

Hi @scott-doyland-burrows thank you for supplying the configuration and Terraform CLI output.

I'm unable to reproduce with this configuration:

resource "random_password" "pwapi_primary" {
  length      = 32
  min_lower   = 10
  min_numeric = 12
  min_upper   = 10
  special     = false
}

By first applying it with 3.3.2 then again with 3.4.2.

I see the same issue as described in random_password Showing Unexpected Plan 3.3.2 to 3.4.2

I can not recreate it either when running from scratch, my statefile after a brand new run using 3.3.2 shows
"min_special" : 0

However my statefile from my actual terraform run from a month ago shows:
"min_special": null
So I presume an even older provider version was setting "min_special" : null (or at some point I set it in my code and later removed it).

So, applying against the statefile that has "min_special" : null using the above resource settings:
3.3.2 does NOT alter the resource.
3.4.2 does alter the resource.

So it looks to me like 3.3.2 considers null and 0 to be the same.
But 3.4.2 considers null and 0 to be different.

[bendbennett]

@scott-doyland-burrows thanks for the clarification.

@lra can you confirm that you have the following in your state file prior to running terraform apply with v3.4.2:

"lower": null
"min_lower": null
"min_numeric": null
"min_special": null
"min_upper": null
"number": null
"numeric": null
"special": null
"upper": null

[lra]

The resource mentioned does not exist anymore, but I have others, here's one: module.stack.module.eks.random_password.strongdm_admin_token

resource "random_password" "strongdm_admin_token" {
  depends_on = [aws_eks_cluster.this]

  length = 928
  lifecycle {
    ignore_changes = all
  }
}

With hashicorp/random v3.3.2:

No changes. Your infrastructure matches the configuration.

          "attributes": {
            "bcrypt_hash": "REDACTED",
            "id": "none",
            "keepers": null,
            "length": null,
            "lower": null,
            "min_lower": null,
            "min_numeric": null,
            "min_special": null,
            "min_upper": null,
            "number": null,
            "numeric": null,
            "override_special": null,
            "result": "REDACTED",
            "special": null,
            "upper": null
          },

And if I terraform plan with v3.4.2:

Terraform will perform the following actions:

  # module.stack.module.eks.random_password.strongdm_admin_token must be replaced
-/+ resource "random_password" "strongdm_admin_token" {
      ~ bcrypt_hash = (sensitive value)
      ~ id          = "none" -> (known after apply)
      + length      = 928
      + lower       = true # forces replacement
      + min_lower   = 0 # forces replacement
      + min_numeric = 0 # forces replacement
      + min_special = 0 # forces replacement
      + min_upper   = 0 # forces replacement
      + number      = true # forces replacement
      + numeric     = true # forces replacement
      ~ result      = (sensitive value)
      + special     = true # forces replacement
      + upper       = true # forces replacement
    }

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

Hope it helps!

[scott-doyland-burrows]

@scott-doyland-burrows thanks for the clarification.

@lra can you confirm that you have the following in your state file prior to running terraform apply with v3.4.2:

"lower": null
"min_lower": null
"min_numeric": null
"min_special": null
"min_upper": null
"number": null
"numeric": null
"special": null
"upper": null

I have this in my statefile currently, which causes NO diff when running against provider 3.3.2 - but causes the min_special diff with 3.4.2.

"attributes": {
  "bcrypt_hash": "REDACTED",
  "id": "none",
  "keepers": null,
  "length": 32,
  "lower": true,
  "min_lower": 10,
  "min_numeric": 12,
  "min_special": null,
  "min_upper": 10,
  "number": true,
  "numeric": true,
  "override_special": null,
  "result": "REDACTED",
  "special": false,
  "upper": true
},

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.