HashiCorp has announced the release of the 1.3 version of Terraform. This release introduces optional object type attributes with defaults and expands the capabilities of moved blocks.
Using Terraform's type constraints, module authors are able to validate the type of value supplied to input variables. To handle complex scenarios an object type is commonly used, allowing for a collection of named attributes to each have their own type. Unfortunately, this meant that module consumers were required to provide values for all attributes, including those not relevant to the task at hand.
With this release, it is now possible to provide default value for attributes within an object. This feature was originally added in Terraform 0.14 under experimental support. The example below shows setting a default value when defining a variable:
variable "buckets" {
type = list(object({
name = string
enabled = optional(bool, true)
website = optional(object({
index_document = optional(string, "index.html")
error_document = optional(string, "error.html")
routing_rules = optional(string)
}), {})
}))
}
The default parameter is optional and if not specified, Terraform will use a null value of the appropriate type as the default. When specified as a non-null default value, the attribute is guaranteed to never have the value null within the receiving module. Terraform will provide the default value both when the caller neglects to set the attribute and when the caller explicitly sets it to null.
The moved block was introduced in version 1.1 to provide a programmatic method for refactoring resources within a config file. Terraform compares the previous state with the new configuration using each module or resource's address. Moving or renaming an object informs Terraform to destroy the object at the old address and to create a new object at the new address. Leveraging the moved block within the configuration file causes Terraform to instead treat the existing object at the old address as if it now belongs at the new address.
The behavior is the same as the terraform state mv command, however the moved block allows for tracking resource moves directly within the configuration file. In its initial release, the moved block only supported refactoring between modules within the same local path.
This release removes that limitation by adding the ability to refactor resources into third-party and separately sourced blocks. This includes modules sourced from the Terraform Registry, a private registry hosted within Terraform Cloud, or any of the options available through the source argument.
The 1.3 release aligns closely with the Terraform v1.0 Compatibility Promise which stated that upgrades within the 1.x versions would have no impact to workflows or the need to upgrade any tooling. While most users will not have impact from the upgrade, there are a few behaviors that may require additional upgrade steps. For example, the 1.3 release sees the deprecation of a few unmaintained state storage backends including: artifactory, etcd, etcdv3, manta, and swift.
More details around the 1.3 release can be found within the documentation or in the changelog. Terraform 1.3 is available for download from the HashiCorp site as well as for use within Terraform Cloud.