Fabric Fast: why the distinction in the documentation of sometimes parsing in values to an optional default argument?

[justinphebey]

Hi

In the bootstrap docs it usually shows values being parsed in to the process using a variable block like the following one even though an optional default argument exists. However, for the Group names, mapping from the GCP checklist ones to an equivalent such as we have because we distinguish our security group names from regular email accounts, the docs show these being parsed in using the default argument of the variable instead. Is there an advantage to the Group names example, parsing the values into the default argument instead?

snippet from fabric fast bootstrap readme:

#locations for GCS, BigQuery, and logging buckets created here
locations = {
  bq      = "EU"
  gcs     = "EU"
  logging = "global"
  pubsub  = []
} 

snippet from fabric fast bootstrap, variables.tf

variable "locations" {
  description = "Optional locations for GCS, BigQuery, and logging buckets created here."
  type = object({
    bq      = optional(string, "EU")
    gcs     = optional(string, "EU")
    logging = optional(string, "global")
    pubsub  = optional(list(string), [])
  })
  nullable = false
  default  = {}
}

snippet from fabric fast bootstrap readme:

variable "groups" {
  description = "Group names to grant organization-level permissions."
  type        = map(string)
  default = {
    gcp-network-admins = "net-rockstars"
    # [...]
  }
}

snippet from fabric fast bootstrap, variables.tf

variable "groups" {
  description = "Group names or IAM-format principals to grant organization-level permissions. If just the name is provided, the 'group:' principal and organization domain are interpolated."
  type = object({
    gcp-billing-admins      = optional(string, "gcp-billing-admins")
    gcp-devops              = optional(string, "gcp-devops")
    gcp-network-admins      = optional(string, "gcp-vpc-network-admins")
    gcp-organization-admins = optional(string, "gcp-organization-admins")
    gcp-security-admins     = optional(string, "gcp-security-admins")
    # aliased to gcp-devops as the checklist does not create it
    gcp-support = optional(string, "gcp-devops")
  })
  nullable = false
  default  = {}
}

Kind regards
Justin

[juliocc]

I'm not sure what the question is but we generally prefer to use optional fields with default values for object-typed variables. This approach allows you to override individual fields without specifying values for every field.

For instance, consider this variable definition:

variable "locations" {
  description = "Optional locations for GCS, BigQuery, and logging buckets created here."
  type = object({
    bq      = string
    gcs     = string
    logging = string
    pubsub  = list(string)
  })
  nullable = false
  default  = {
    bq      = "EU"
    gcs     = "EU"
    logging = "global"
    pubsub  = []
  } 
}

In this case, changing only the gcs location requires specifying values for all other fields.

Our preferred approach is to use optional with default values:

variable "locations" {
  description = "Optional locations for GCS, BigQuery, and logging buckets created here."
  type = object({
    bq      = optional(string, "EU")
    gcs     = optional(string, "EU")
    logging = optional(string, "global")
    pubsub  = optional(list(string), [])
  })
  nullable = false
  default  = {}
}

This allows you to set locations = { gcs = "myvalue" } while retaining the default values for other fields.

Please note that our approach has changed over time as Terraform's type system evolved. You might encounter inconsistencies in the codebase reflecting these changes.

Hope this answers your question

[justinphebey]

Yes, thank you.

I wasn't sure if the default argument block was being called out specifically in the docs because it was necessary for some inheritance reason to subsequent stages. You appear to be saying both styles achieve the same thing but the newer inline style is now preferred. That makes sense because it offers better brevity, maintainability without so much risk of inadvertently wiping out a newer option later added to the underlying terraform stage / module. I guess the separate default argument blocks remain in the underlying code to be one less risk of causing a breaking change to someone using the older option.

Kind regards
Justin