Optional object attributes whithin a module

Terraform
1

Dear Community,

We developed a module to deploy a PostgreSQL Flexible Server in Azure using official azurerm provider. This module use azurerm_postgresql_flexible_server resource type for the flexible server itself and azurerm_postgresql_flexible_server_configuration resource type for the server parameters.

For the server parameters, we would like to be able to propose default values while being able to override a single value. So, we decided to define a variable of type object with optional attributes as documented here: https://developer.hashicorp.com/terraform/language/expressions/type-constraints#optional-object-type-attributes.

When trying to use this module in a root module, we realized that we have to redefine the variable within the root module exactly as in the module for the overrides to be taken into account.

Is it an expected behaviour or did we miss something?

Best regards, Olivier

PS: If necessary, we can provide variable definition and overrides.

Wrong type-checking with conditionals?
2

Generally, yes it’s what I would expect. If you want to carry comprehensive type checking all the way through to object attributes from the root module’s input variables through to the child module there’s a lot of repetition.

  1. Your tfvars files deserve some sort of documentation, even if that commented out optional values in a template. Otherwise there’s a lot of back and forth with variables complex enough to have maps of objects (maybe with more levels of maps of objects like systems and disks).
  2. Root module’s variables.tf definitions
  3. Possibly in the calls to the child module from the root module depending on exactly what you’re doing
  4. Child module’s variables.tf

Additionally, for robustness and long term maintenance I don’t rely only on the variable type definitions to protect this. In strategic places I’ll refer to it as try(reference, default)to protect against the possibility that reference might be missing. When that happens, confusingly the error message refers to deep in the child module instead of the tfvars file which is the source of the error.

I figure it’s too likely that a future maintainer will disable the type checking to silence an error. Or that they or I will make a mistake in a complex type. Or a complex for expression manipulating structures won’t get it quite right.

-Scott-

3

There are some other quirks with using objects around validation and / or undefined elements, including the one documented here and here.

See this discussion. Even though using objects often feels like the “right” solution, I’ve found that sometimes using map(any) or similar ends up working better.

4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.