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