Optional arguments in object variable type definition

[prehor]

Current Terraform Version

Terraform v0.12.0-alpha4 (2c36829d3265661d8edbd5014de8090ea7e2a076)

Proposal

I like the object variable type and it would be nice to be able to define optional arguments which can carry null value too, to use:

variable "network_rules" {
  default = null
  type = object({
    bypass = optional(list(string))
    ip_rules = optional(list(string))
    virtual_network_subnet_ids = optional(list(string))
  })
}

resource "azurerm_storage_account" "sa" {
  name = random_string.name.result
  location = var.location
  resource_group_name = var.resource_group_name
  account_replication_type = var.account_replication_type
  account_tier = var.account_tier

  dynamic "network_rules" {
    for_each = var.network_rules == null ? [] : list(var.network_rules)

    content {
      bypass = network_rules.value.bypass
      ip_rules = network_rules.value.ip_rules
      virtual_network_subnet_ids = network_rules.value.virtual_network_subnet_ids
    }
  }

instead of:

variable "network_rules" {
  default = null
  type = map(string)
}

resource "azurerm_storage_account" "sa" {
  name = random_string.name.result
  location = var.location
  resource_group_name = var.resource_group_name
  account_replication_type = var.account_replication_type
  account_tier = var.account_tier

  dynamic "network_rules" {
    for_each = var.network_rules == null ? [] : list(var.network_rules)

    content {
      bypass = lookup(network_rules, "bypass", null) == null ? null : split(",", lookup(network_rules, "bypass"))
      ip_rules = lookup(network_rules, "ip_rules", null) == null ? null : split(",", lookup(network_rules, "ip_rules"))
      virtual_network_subnet_ids = lookup(network_rules, "virtual_network_subnet_ids", null) == null ? null : split(",", lookup(network_rules, "virtual_network_subnet_ids"))
    }
  }
}

[abymsft]

I'd really like to have this option too. Any plans of prioritizing this enahancement ?

[rverma-nikiai]

is there a workaround for this? I found myself using type=any

[sudoforge]

@rverma-nikiai No, there is not currently a workaround for this.

The best thing we can do is define the optional argument as such (where foobar is the optional property):

modules/myfoo/main.tf

variable "foo" {
  type = object({
    name   = string
    id     = number
    foobar = string # or bool, number, etc...
  })
}

resource "null_resource" {
  triggers = {
    some_name   = var.foo.name
    some_id     = var.foo.id
    some_foobar = var.foo.foobar
  }
}

... and then call it, explicitly setting the optional properties to null

main.tf

module "potato" {
  source = "./modules/myfoo"
  foo = {
    name   = "something-cool-is-afoot"
    id     = 1234567890
    foobar = null
  }
}

This allows you to do normal stuff like set defaults using a ternary check, eg.:

modules/myfoo/main.tf

locals {
  foobar_default = var.foo.foobar == null ? "default value for foo.foobar" : null
}

...

[thefotios]

Along the same lines, it would be useful to be able to declare partial defaults for complex types

For instance, something like

variable "with_default_path" {
  type = object({
    id = string
    path = string
  })
 
  default = {
    path = "/"
  }
}

[mildwonkey]

Hi folks! This is a great feature request, and getting use-cases is absolutely helpful, but so you know it best to react to the original issue comment with 👍which we can and do report on during prioritization.
Thank you :)

[LinguineCode]

Along the same lines, it would be useful to be able to declare partial defaults for complex types

For instance, something like

variable "with_default_path" {
  type = object({
    id = string
    path = string
  })
 
  default = {
    path = "/"
  }
}

Absolutely, this should be part of the original post as well

👍 Optional values
👍 Partial default values

[sudoforge]

@solsglasses - please add reactions to comments, pull requests, or issues instead of creating a new comment simply to show agreement with someone. Thanks for helping to keep the community awesome, and the notification feed of -- well, everyone -- free of fluff!

[thefotios]

I'm not sure of the internals, but this may not be that difficult. Since type and defaults are already well defined, the parser would just need to allow both of them and then merge the defaults with the provided variable before validation.

My proposal mostly dealt with optional values inside the type definition, not the argument itself being optional. The might get a little trickier. Having the argument be optional is going to lead to a lot of lines like:

for_each = var.network_rules == null ? [] : list(var.network_rules)

It may make more sense for the default value to match the type definition. So a list(object(...)) would return an empty list. This way you can let the parser handle the null check and you can be guaranteed to get the proper type for iteration. This is assuming that an empty list is valid for the type definition of list(object(...)).

It could reduce a bunch of boilerplate code if there was an optional flag in the variable definition.

[atavakoliyext]

Update: I created #22449 to track this.

---

One more proposal to add to the mix:

object({
  <KEY> = <TYPE | { [type = <TYPE>,][ default = ...] }>
})

I think would allow more readable complex object definitions in cases where defaults could appear at any level, and would have parity with how defaults in variable blocks are defined. For a contrived example:

variable "pipeline" {
  type = object({
    name = string

    pipeline_type = {
      type = string        // inferred from default & can be omitted
      default = "STANDARD"
    }

    stages = {
      type = list(object({
        name      = string
        cmd       = string
        must_pass = { default = false }
        }
      }))

      default = [
        {
          name      = "build"
          cmd       = "make all"
          must_pass = true
        },
        {
          name = "deploy"
          cmd  = "make deploy"
        },
      ]
    }
  })

  default = {
    name = "standard_build_pipeline"
    // everything else is taken from the type defaults
  }
}

(the use-case for having both type and default in the block would be for when the type can't be inferred from the default, such as when default = null).

[morgante]

For what it's worth, even the minimal behavior (accepting objects with omitted values and setting the omitted values to null) would be a major usability improvement. Defaults could be implemented within modules themselves.