hashicorp / terraform-provider-random

Utility provider that supports the use of randomness within Terraform configurations.
https://registry.terraform.io/providers/hashicorp/random/latest
Mozilla Public License 2.0
203 stars 117 forks source link

`provider::random::string()` function #569

Closed imjasonh closed 6 months ago

imjasonh commented 6 months ago

Terraform CLI and Provider Versions

This would require Terraform 1.8+

Use Cases or Problem Statement

Generate a random value in a way that doesn't persist it in state, unlike resource "random_string", which persists the random value for reuse in a later invocation.

Proposal

Add a provider-defined function for random_string, pet, etc., to generate and return a new random string every time the function is invoked.

How much impact is this issue causing?

Low

Additional Information

This would probably require some education/documentation about when to prefer random_string over the function -- in many cases I suspect most people would still want random_string, but there are times when a true random string, generated each time the function is invoked, can be useful.

https://developer.hashicorp.com/terraform/plugin/framework/functions/concepts

Code of Conduct

bflad commented 6 months ago

Hi @imjasonh 👋 Thank you for raising this feature request. It might be helpful to understand some of the anticipated use cases, e.g. is this for testing Terraform modules or some other situation?

Provider-defined functions intentionally have some fundamental design considerations that are at odds with this type of feature request. Essentially Terraform requires that provider-defined functions are implemented as pure functions, or in other words, given the same input, it should always return the same output. Terraform automatically performs some level checking for this during its operations and will raise an error if it detects this sort of issue.

Quick aside: The built-in Terraform timestamp() function, which does change values each invocation, is not a provider-defined function and can work around limitations such as this by nature of being baked directly into the Terraform core runtime.

While a provider-defined function would not be suitable for this case, there still can be a provider-based solution. In this case, it would be to introducing a random_string data resource, where in Terraform that lifecycle is okay with returning different results each invocation. Since data resources are supported for all versions of Terraform that this provider supports today, there would be no Terraform version restriction on usage.

If this provider was able to offer a data resource, e.g.

data "random_string" "example" {}

# data.random_string.example.result available elsewhere

Would that suffice for your use case? Thanks!

imjasonh commented 6 months ago

Essentially Terraform requires that provider-defined functions are implemented as pure functions, or in other words, given the same input, it should always return the same output.

That's useful context, and if that's the case, then yeah a random_string provider function wouldn't make sense. There's already a random_string resource which we use regularly, and works fine.

I'll close this, since it sounds like this isn't in keeping with the spirit of provider-defined funcs.