Do not create a random password if a admin_password is provided to the VM module

[stiross79]

Module Name

vm

Description

Only create the random password resource if an admin_password has not been provided.

Example Terraform Configuration

resource "random_password" "this" {
  count       = var.admin_password != null ? 1 : 0
...
}

[hknutsen]

Might not be possible, see #119. Depends on how your custom admin password is generated though.

[stiross79]

Might not be possible, see #119. Depends on how your custom admin password is generated though.

In our case, we already have our VMs with a random password stored in the state. With the current config, we will have two random_password resources, but only one that will be used.

[stiross79]

@hknutsen What value will not be known during the planning?

[hknutsen]

Consider the following example configuration:

resource "random_password" "custom" {
  length      = 128
  lower       = true
  upper       = true
  numeric     = true
  special     = true
  min_lower   = 1
  min_upper   = 1
  min_numeric = 1
  min_special = 1
}

resource "random_password" "default" {
  count = random_password.custom.result == null ? 1 : 0

  length      = 16
  lower       = true
  upper       = true
  numeric     = true
  special     = true
  min_lower   = 1
  min_upper   = 1
  min_numeric = 1
  min_special = 1
}

Assumptions:

• random_password.default is the password generated by the vm module.
• random_password.custom is the custom password you pass to the vm module.

Running terraform plan throws the following error:

$ terraform plan
╷
│ Error: Invalid count argument
│
│   on main.tf line 14, in resource "random_password" "default":
│   14:   count = random_password.custom.result == null ? 1 : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources   
│ that the count depends on.
╵

This is because the random_password resource generates a password. Generated values are not known until the after the resource has been created by terraform apply.

Note that the error message specifies that you can use terraform apply -target=... to work around this, however it seems like a flaky workaround to me.

[stiross79]

I would agree if you relied on the output result from another resource within the module for the count argument. But in our case, we are referring to a variable that is either supplied by its consumer or defaults to null, the same way we determine whether to create a Linux or Windows VM resource based on the is_windows local.

count = local.is_windows ? 0 : 1

[hknutsen]

But if the provided value of that variable comes from a resource, you can run into the same problem.

Basically, the suggested implementation would completely remove the possibility of providing a custom password generated by Terraform.

The current implementation of this module has no such issues, the only downside is that if you provide a custom password, the password generated by this module will still exist in your state, though remain unused.

[stiross79]

I have used the same strategy before without encountering any problems. But it is not a big deal and we can leave the random password resource in 😄

[hknutsen]

Leaving the issue open for a little longer though, in case we come up with a solution 🙌

[hknutsen]

Might be worth taking a new look at this once Terraform 1.9 has been released:

The experimental "deferred actions" feature, enabled by passing the -allow-deferral option to terraform plan, permits count and for_each arguments in module, resource, and data blocks to have unknown values and allows providers to react more flexibly to unknown values. This experiment is under active development, and so it's not yet useful to participate in this experiment.

From changelog.

[github-actions]

There has been no activity on this issue for 60 days. stale label will be added. If no additional activity occurs, the issue will be closed in 14 days.

[helenakallekleiv]

Might be worth taking a new look at this once Terraform 1.9 has been released:

The experimental "deferred actions" feature, enabled by passing the -allow-deferral option to terraform plan, permits count and for_each arguments in module, resource, and data blocks to have unknown values and allows providers to react more flexibly to unknown values. This experiment is under active development, and so it's not yet useful to participate in this experiment.

From changelog.

As of today, the "deferred actions" feature is still labed as an experiment in the alpha pre-release of Terraform 1.10, so we might have to wait a while for it.

I think we can close this issue for now and rather keep an eye on the changelog for when the "deferred actions" feature moves out from the experimentation stage.

Any other thoughts @equinor/terraform-baseline-maintainers?