I'm trying to create a module that creates interconnect-attachments, but some parts are only defined if the attachment is using ipsec encryption and if it's not, that block must not exist in the resource else it causes an error (even if it only contains a value set to null.)
I've tried using a dynamic, but I can't quite get the layout right to have it work:
resource "google_compute_interconnect_attachment" "interconnect-attachment" {
project = var.project
region = var.region
name = var.name
edge_availability_domain = var.availability_domain
type = var.type
router = google_compute_router.router.name
encryption = var.encryption
dynamic "ipsec_internal_addresses" {
for_each = var.encryption != "IPSEC" ? [] : [1]
content {
var.address
}
}
}
Essentially, if var.encryption is set to IPSEC then i want the following block included:
ipsec_internal_addresses = [
var.address,
]
The other issue is it appears a dynamic block expects some kind of assignment to happen, but the terraform examples just have the value inside the ipsec_internal_addresses so I'm unsure how to to achieve this.
ipsec_internal_addresses is not a block in the google_compute_interconnect_attachment resource. It is an argument. Therefore, you can use the normal pattern for specifying optional arguments where the conditional returns a null type if you do not want to specify a value. Using your conditional and variables:
ipsec_internal_addresses = var.encryption == "IPSEC" ? [var.address] : null
which will return and assign your [var.address] to ipsec_internal_addresses when var.encryption equals the string IPSEC. Otherwise, it will return null and the ipsec_internal_addresses argument will be ignored.
Related
I'm currently using the terraform-aws-eks module and wanted to setup a managed node group in an existing cluster. However, I only want this node group to appear in our dev environment (but still want the cluster to remain unchanged). Is there a way to skip a variable assignment conditionally for a module? I tried the below approach but get an error if var.deploy_managed_node_group = false. Terraform version 0.14.11.
module "eks" {
source = "./modules/eks-17.24.0"
cluster_enabled_log_types = var.cluster_enabled_log_types
cluster_name = local.eks_cluster_name
cluster_version = local.eks_version
iam_path = "/eks/"
manage_aws_auth = true
map_users = local.eks_users
map_roles = local.eks_roles
subnets = module.eks_vpc.private_subnets
vpc_id = module.eks_vpc.vpc_id
worker_groups = local.worker_groups
node_groups = var.deploy_managed_node_group ? local.node_groups : null
}
Error: Iteration over null value
node_groups variable from module:
variable "node_groups" {
description = "Map of map of node groups to create. See `node_groups` module's documentation for more details"
type = any
default = {}
}
When using types in Terraform such as set, list, or map, the omitted value should be "empty" instead of null if the value is utilized for iteration instead of an argument. Therefore:
node_groups = var.deploy_managed_node_group ? local.node_groups : {}
would be the ideal ternary here as the falsey value returned by the conditional is an empty map constructor.
myvar should be a list of security groups.
variable "myvar" {
default = null
}
If users specify it that list is concatenated with the default security group (pulled in from the data source).
If it's not specified just use the default security group.
This is not working:
local {
test = var.myvar != null ? concat(tolist(data.aws_security_group.data.id), var.myvar) : tolist(data.aws_security_group.data.id)
}
But this does work:
aaa = var.myvar != null ? concat(["aaaa"], ["bbbbb","ccccccc"]) : ["aaaa"]
So how to I convert a string to a scalar array/list? It seems like that's what Terraform needs and tolist() is not working.
Based on the given requirements, I think the most straightforward solution would be to set the default for the variable to [] and avoid the need for conditionals at all:
variable "additional_security_group_ids" {
type = list(string)
default = []
}
locals {
security_group_ids = concat(
[data.aws_security_group.default.id],
var.additional_security_group_ids,
)
}
Concatenating an empty list just produces the same list, so leaving the variable unset in the above would cause local.security_group_ids to contain only the default security group id.
Setting the default to null is useful when the absence of a value for that variable disables some feature entirely, or if the logic you need can't be conveniently expressed via defaults, but I'd always recommend using specific default values where possible because the result will tend to be easier to read and understand for future maintainers.
Is this what you're looking for?
value = var.myvar != null ? concat([data.aws_security_group.data.id], var.myvar) : [data.aws_security_group.data.id]
Proposing this as answer, but hoping there is a less crazy way
local {
test = var.myvar != null ? flatten(concat(tolist([data.aws_security_group.data.id]), [var.myvar])) : tolist([data.aws_security_group.data.id])
}
I have a module that controls a handful of similar resources, and many of the settings in those resources are the same; so I've created global defaults that all of the resources in my module can refer to.
I want to have a set of default variables in my module and a set of variables that can override the default if the caller of my module decides to pass those in. What I've been using for strings is below (these are all in the same variables.tf file in my module).
My defaults:
variable "default_env" {default="test"}
My placeholder variables to allow calling resources to set them:
variable "x_env" {default=""}
variable "y_env" {default=""}
variable "z_env" {default=""}
And my attempt at guiding the user of the module towards which variables should be available for being overridden:
locals {
env = "${var.x_env != "" ? var.x_env : "${var.default_env}"}"
env = "${var.y_env != "" ? var.y_env : "${var.default_env}"}"
env = "${var.z_env != "" ? var.z_env : "${var.default_env}"}"
}
However, I can't figure out how to do this properly with booleans because I can't figure out how to create an empty boolean variable. My only option seems to be to also set a default value as part of my override variables:
variable "x_lock" {default=true}
Is there a way I can declare this in such a way that we don't have to maintain two sets of default values (1: variable "default_lock" {default=true}, 2: variable "x_lock" {default=true})?
I've tried doing:
variable "x_lock" {
type = bool
default = ""
}
But I obviously get an error that "" is not compatible with bool.
How else can I go about this?
The absence of a value is represented in Terraform by the keyword null, which is valid for any type.
Given that, in order to distinguish between true, false, and not set at all you can define a variable like this:
variable "x_lock" {
type = bool
default = null
}
Note that it's not really true to say that this is "the equivalent of an empty string for booleans". An empty string is not equal to null, and so if you want to explicitly represent the absence of a string it can often be best to use null for that too:
variable "x_env" {
type = string
default = null
}
...that way you can recognize an empty string as distinct from no string at all, similar to distinguishing false from no boolean at all.
null has a slightly different meaning in the context of a default than it does elsewhere. Setting default = null specifies that an input variable is optional without providing a default value for it. Or, if you like, saying that its default value is null.
An advantage of using null in this way is that you can pass that argument on as-is to any optional resource argument and it will be interpreted as if that argument were not set at all, rather than as if it were set to a default value.
There is also a further "special power" for null: if you use the splat operator [*] with a non-list value then it will return a single-element list for a non-null value and an empty list for a null value. This can be particularly useful if you are intending to use the "null-ness" of the value to decide whether or not to create a resource or a nested block:
variable "subscription_id" {
type = string
default = null
}
data "azurerm_subscription" "example" {
# Will be an empty set if `var.subscription_id` is null, or
# a single-item set if it is a non-null string.
for_each = toset(var.subscription_id[*])
subscription_id = each.key
}
Is there a way to detect the type of a variable in Terraform? Say, I have a module input variable of type any, can I do some kind of switch, depending on the type?
variable "details" {
type = any
}
local {
name = var.details.type == map ? var.details["name"] : var.details
}
What I want to archive is, to be able to pass either a string as shorthand or a complex object with additional keys.
module "foo" {
details = "my-name"
}
or
module "foo" {
details = {
name = "my-name"
age = "40"
}
}
I know this example doesn't make much sense and you would like to suggest to instead use two input vars with defaults. This example is just reduced to the minimal (non)working example. The end goal is to have a list of IAM policy statements, so it is going to be a list of lists of objects.
Terraform v0.12.20 introduced a new function try which can be used to concisely select between different ways of retrieving a value, taking the first one that wouldn't produce an error.
variable "person" {
type = any
# Optional: add a validation rule to catch invalid types,
# though this feature remains experimental in Terraform v0.12.20.
# (Since this is experimental at the time of writing, it might
# see breaking changes before final release.)
validation {
# If var.person.name succeeds then var.person is an object
# which has at least the "name" attribute.
condition = can(var.person.name) || can(tostring(var.person))
error_message = "The \"person\" argument must either be a person object or a string giving a person's name."
}
}
locals {
person = try(
# The value of the first successful expression will be taken.
{name = tostring(var.person)}, # If the value is just a string
var.person, # If the value is not a string (directly an object)
)
}
Elsewhere in the configuration you can then write local.person.name to obtain the name, regardless of whether the caller passed an object or a string.
The remainder of this answer is an earlier response that now applies only to Terraform versions between v0.12.0 and v0.12.20.
There is no mechanism for switching behavior based on types in Terraform. Generally Terraform favors selecting specific types so that module callers are always consistent and Terraform can fully validate the given values, even if that means a little extra verbosity in simpler cases.
I would recommend just defining details as an object and having the caller explicitly write out the object with the name attribute, in order to be more explicit and consistent:
variable "details" {
type = object({
name = string
})
}
module "example" {
source = "./modules/example"
details = { name = "example" }
}
If you need to support two different types, the closest thing in the Terraform language would be to define two variables and detect which one is null:
variable "details" {
type = object({
name = string
})
default = null
}
variable "name" {
type = string
default = null
}
local {
name = var.name != null ? var.name : var.details.name
}
However since there is not currently a way to express that exactly one of those two must be specified, the module configuration you write must be ready to deal with the possibility that both will be set (in the above example, var.name takes priority) or that neither will be set (in the above example, the expression would produce an error, but not a very caller-friendly one).
terraform v1.0+ introduces a new function type() for this purpose. See https://www.terraform.io/language/functions/type
I have a variable that the user will input during run time. Lets say the variable name is region. However, I want the execution to be only successful if the user picks a value from one of the values defined in a list/ choices.
how can I restrict it so the user's selection has to match values that are considered acceptable in the variable definition?
Stumbled across this question.
Since v0.13.0 input validation has been possible directly via the input variables. Thus you can actually achieve this with a snippet such as below.
variable "test_variable" {
type = string
description = "some test value"
validation {
condition = contains(["item1", "item2", "item3"], var.test_variable)
error_message = "Valid values for var: test_variable are (item1, item2, item3)."
}
}
Read more here - https://www.hashicorp.com/blog/custom-variable-validation-in-terraform-0-13
One solution:
variable "values_list" {
description = "acceptable values"
type = "list"
default = ["true", "false"]
}
variable "somevar" {
description = "must be true or false"
}
resource "null_resource" "is_variable_value_valid" {
count = "${contains(var.values_list, var.somevar) == true ? 0 : 1}"
"ERROR: The somevar value can only be: true or false" = true
}
If you pass a value different than "true" or "false" for the "somevar" variable, Terraform will throw an error and stop. The disadvantage is that you have to list all values in the default block of values_list.
Source: https://stackoverflow.com/a/54256780/1364793
Terraform currently has no first-class feature for this, but you can achieve the desired effect (albeit with a less-helpful error message) by asking Terraform to look the value up in a map:
variable "example" {
description = "must be a, b, or c"
}
locals {
allowed_example_values = { for v in ["a", "b", "c"] : v => v }
checked_example = local.allowed_example_values[var.example] # will fail if var.example is invalid
}
Because the values in the allowed_example_values map are the same as the keys, you can then use local.checked_example in place of var.example everywhere else in the module to set up the dependency graph such that it's impossible for an invalid value to be used.
Some caveats/limitations:
You can't customize the error message that Terraform will return when the value is invalid. Instead, Terraform will return the generic error about the key not matching any element in the map. However, it will include the source code snippet from the affected line in the error message (in Terraform 0.12 or later) so the comment at the end of that line should be visible in the error message and thus provide an additional clue to the user as to what might be wrong.
This works fully only for string values, because map keys are always strings in Terraform. Using other primitive types can work as a result of Terraform's automatic conversions from bool and number to string, but you should be sure to explicitly declare the type of the variable (using e.g. type = number) to ensure that Terraform will normalize incoming values into the expected type before looking them up in the map. This technique will not work at all for collection and structural types.
I wouldn't suggest using strings "true" and "false" since Terraform has a bool type which can represent that more intuitively. If you are using Terraform 0.11 and earlier then it's not possible to constrain to bool, but in Terraform 0.12 and later you can declare a variable as type = bool and then Terraform will handle the validation automatically.