How do I do variable definitions in locals? - terraform

Question

So I have this variable that I want to interpolate like this:
variable "secondary_ranges" {
type = map(object({
secondary_range = object({
range_name = string
ip_cidr_range = string
})
}))
default = {
pods = {
secondary_range = {
range_name = "pods"
ip_cidr_range = "${var.some_other_var_or_datasource}"
}
}
services = {
secondary_range = {
range_name = "services"
ip_cidr_range = "${var.some_other_var_or_datasource}"
}
}
}
}
I can do this in locals but I loose my custom type definition
locals {
default = {
pods = {
secondary_range = {
range_name = "pods"
ip_cidr_range = "${var.some_other_var_or_datasource}"
}
}
services = {
secondary_range = {
range_name = "services"
ip_cidr_range = "${var.some_other_var_or_datasource}"
}
}
}
}
Is there a way to apply a custom type in locals?

Answer 1

You can make the local value end up having a type that conforms to that variable type constraint by including some type conversion functions (tomap and tostring):
locals {
default = tomap({
pods = {
secondary_range = {
range_name = "pods"
ip_cidr_range = tostring(var.some_other_var_or_datasource)
}
}
services = {
secondary_range = {
range_name = "services"
ip_cidr_range = tostring(var.some_other_var_or_datasource)
}
}
})
}
The { ... } syntax creates a value of an object type, but we can pass such an object to tomap to have Terraform convert it to an equivalent map type. It'll do that by checking that all of the object attribute values have the same type and selecting that type as the map's element type, and so the resulting value will have the same type as long as the objects inside have the right structures.
In the example above I helped ensure that the result would have the right type by using tostring with each of the two variable references. That wouldn't actually be necessary if that variable were defined as type = string because Terraform would convert it to string automatically anyway, but it doesn't hurt to be explicit if you care about producing a specific result type.
The ability to set a type constraint is there to help a caller of your module know how to call it, so there isn't a direct equivalent of it for values defined within the module itself, but if you use type conversion functions like in the above you can get the same result a different way.
Personally I don't typically worry too much about the types of local values, because they are used only within the current module anyway, but I will be more explicit about type conversions in output values so that the caller can get a better signal about how the value is intended to be used and so that future changes are less likely to inadvertently cause an output value to change to a different type.