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
201 stars 114 forks source link

Feature Request: random IP from CIDR range #517

Open bschaatsbergen opened 7 months ago

bschaatsbergen commented 7 months ago

It would be nice to have a resource that generates random IPv4 or IPv6 addresses within a specified CIDR range.

Why: I'm sure this can serve various purposes, as people are more creative than I am.

Use cases I can think of:

Example usage

Basic:

resource "random_ip" "example" {}

IPv4:

resource "random_ip" "example" {
  cidr_range   = "192.168.0.0/24"
}

IPv6:

resource "random_ip" "example" {
  cidr_range   = "2001:db8::/32"
}

Using a count:

resource "random_ip" "example" {
  count        = 5
  cidr_range   = "2001:db8::/32"
}

output "random_ipv6_addresses" {
  value = random_ip.example[*].result
}

Using a count followed by a distinct:

resource "random_ip" "example" {
  count        = 50
  cidr_range   = "192.168.1.0/28"
}

output "random_distinct_ipv4_addresses" {
  value = distinct(random_ip.example[*].result)
}

I'm would love to contribute this new resource if it aligns with the vision of this provider and is something we intend to support. :)

bschaatsbergen commented 7 months ago

What are your thoughts on this @bendbennett?

austinvalle commented 7 months ago

Hey there @bschaatsbergen :wave:, thanks for raising this issue!

Just wanted to quickly point out, since the random provider is so heavily used by the community, one of the main design goals is stability over features. That's not to say we won't accept any new feature, but rather we want to ensure that new features aren't being added without ample design consideration. Another piece of consideration was mentioned by @bendbennett, which is interest from the community.

The feature requested here is an expansion of what the random provider does today and it does feel like it could lead the provider down a "slippery slope" of new features related to context-specific random strings. (random time, dates, IPs, emails, etc.)

Use cases I can think of:

Helpful to combine with the terraform test framework, performing egress network connectivity tests against a set of generated IP addresses in a range I'm actively denying or allowing.

If this is the main drive behind this new resource, that might make a good candidate to live in a new provider that focuses on generating realistic mock test data, a Terraform sibling of something like faker-js. The recent addition of test mocking in Terraform 1.7 might make providers that produce realistic fake data like that more desirable.

I see a couple others have upvoted this issue in particular, so if there are any use-cases for random IPs that are not mocking/test data specific, we would be interested to hear about those as well.

bschaatsbergen commented 7 months ago

Hey @austinvalle, appreciate the detailed feedback on the requested feature. I understand the importance of prioritizing stability over additional features, and I agree that we should carefully consider which resources to incorporate into this provider. Has a realistic mock data Terraform Provider been discussed before? If the DevEx team is keen on having this, I would love to kick start this - generating realistic mock data such as dates, IPs, and email addresses. What's your take on this?

austinvalle commented 7 months ago

Has a realistic mock data Terraform Provider been discussed before?

I'm not 100% sure, although my team isn't as involved with the Terraform module testing functionality recently released. I'd imagine folks closer to that community would have a better idea on how useful a provider would really be there. (vs. just hardcoding test data)

If the DevEx team is keen on having this...

The providers our team supports are more focused on RFC-backed functionality (like time (RFC3339), dns, http, tls, etc.) and we don't currently have any plans on expanding that scope. It's possible that could change in the future, but I'd say if you're interested in that type of functionality (mock test data) from a provider then it'd be more appropriate to create a community provider.