lang/funcs: cidrsubnets function #22858
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a companion to cidrsubnet that allows bulk-allocation of multiple subnet addresses at once, with automatic numbering.
Unlike cidrsubnet, cidrsubnets allows each of the allocations to have a different prefix length, and will pack the networks consecutively into the given address space. cidrsubnets can potentially create more complicated addressing schemes than cidrsubnet alone can. It's not possible to achieve variable prefix lengths with
cidrsubnet
(singular) in the Terraform language because it has no reduce-equivalent operator to allow iteratively computing the next address from the previous address.This is a function-oriented version of the core algorithm in
terraform-provider-cidr
. In light of the language improvements in Terraform 0.12, we've been leaning towards using compute-only modules to abstract over calculations rather than using custom Terraform providers, because modules are easier to maintain, release, and distribute.However, the
cidr
provider has at is core an iteration-based algorithm that the Terraform language can't represent. By providing that algorithm as a built-in function (with a similar interface to our existingcidrsubnet
) then it becomes technically possible to use it as the foundation of various IP address scheme calculation modules.After merging this it would be possible to write a Terraform module with an equivalent interface to the
cidr_network
data source, but it can also be used as a building block for more specialized address planning modules, such as my own more-opinionatedterraformnet/addr-plan/cidr
module that currently has some rather awkward restrictions due to being built on the existingcidrsubnet
function.