Provide random data sources

[dmikalova]

Terraform CLI and Provider Versions

Terraform v1.3.7
on darwin_arm64

• provider registry.terraform.io/gavinbunney/kubectl v1.14.0
• provider registry.terraform.io/hashicorp/aws v4.38.0
• provider registry.terraform.io/hashicorp/null v3.2.0
• provider registry.terraform.io/hashicorp/random v3.4.3
• provider registry.terraform.io/kbst/kustomization v0.9.0

Use Cases or Problem Statement

I am trying to generate passwords with the random_password resource, pass that into kustomization_overlay data source, and deploy the output of kustomize with the kubectl_manifest resource. However, kustomize outputs the yaml documents it generates as a list of strings, so kubectl_manifest needs to for_each over those.

If the values passed into kustomize are static then this works. However, if the values are generated by random_password, then I get the "for_each" set includes values derived from resource attributes that cannot be determined until apply error.

To get around this - in a separate TF stack I can put random_password into an AWS SSM parameter, and then in the original TF stack use the aws_ssm_parameter data source and Terraform will be happy with this.

Proposal

random_password and the other random_* resources could have data source equivalents that allow it to be used with for_each.

How much impact is this issue causing?

Medium

Additional Information

No response

Code of Conduct

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

[sb3lxb]

Perhaps this stems from #121

[vuskeedoo]

Also running into this issue with AWS EKS.

│ Error: Invalid for_each argument
│
│ on .terraform/modules/test_eks.eks/main.tf line 96, in resource "aws_ec2_tag" "cluster_primary_security_group":
│ 96: for_each = { for k, v in merge(var.tags, var.cluster_tags) :
│ 97: k => v if local.create && k != "Name" && var.create_cluster_primary_security_group_tags && v != null
│ 98: }
│ ├────────────────
│ │ local.create is true
│ │ var.cluster_tags is empty map of string
│ │ var.create_cluster_primary_security_group_tags is true
│ │ var.tags is map of string with 3 elements
│
│ The "for_each" map includes keys derived from resource attributes that
│ cannot be determined until apply, and so Terraform cannot determine the
│ full set of keys that will identify the instances of this resource.
│
│ When working with unknown values in for_each, it's better to define the map
│ keys statically in your configuration and place apply-time results only in
│ the map values.
│
│ Alternatively, you could use the -target planning option to first apply
│ only the resources that the for_each value depends on, and then apply a
│ second time to fully converge.

[bflad]

Hi folks 👋

Creating data source equivalents of the existing random_* managed resources is likely not too useful in practice. What will happen is that every Terraform planning and refresh operation would propose creating a new, randomized value. There would be no "storage" of the randomized value each time, so plans would permanently include value differences. If that particular use case is useful for you, it should likely be raised as its own feature request that describes the situations where that sort of behavior would be beneficial in practice.

The "for_each" map includes keys derived from resource attributes that cannot be determined until apply type of error is in fact what the #121 feature request would aim to solve. The idea there is that this provider's managed resources could run their randomization logic during planning and return known values for all attributes, rather than the existing behavior of planning and returning unknown (known after apply) values. Terraform currently requires known values for resource instance counts/keys and will raise that error if there are unknown values for those.

Since #121 already exists and having that linked in this comment will automatically create a link back to this particular use case, I'm going to close this issue as a duplicate. If you do feel like the mentioned data source behavior is actually beneficial, please raise a separate issue describing your particular use case. Thank you!

[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.