Terraform 1.8 improves extensibility with provider-defined functions

Today, we are announcing the general availability of HashiCorp Terraform 1.8, which is ready for download and immediately available for use in Terraform Cloud. This version includes two new capabilities to improve the extensibility and flexibility of Terraform: provider-defined functions and refactoring across resource types.

»Provider-defined functions

Terraform includes a wide selection of built-in functions to perform many common operations during provisioning. While they address many general use cases, there have been many requests from the community for more specialized functions and custom logic. With Terraform 1.8, we are excited to introduce provider-defined functions, which allow anyone in the community and HashiCorp’s partner ecosystem to extend the capabilities of Terraform.

Provider-defined functions can be used in any Terraform expression, including input validation conditions, output values, local values, data sources, and resource blocks. Additionally, provider-defined functions can be used with checks and tests, which commonly require more complex business logic to write custom assertions that address unique validation scenarios. Provider-defined functions are invoked with the syntax provider::<provider_name>::<function_name>([arguments]). Examples of available functions include rfc_3339_parse in v0.11 of the official time provider and direxists in v2.5 of the local provider.

An initial set of functions are now available in the AWS, Google Cloud, and Kubernetes providers. For more details and examples, check out Terraform 1.8 provider functions for AWS, Google Cloud, and Kubernetes. The latest version of the HashiCorp Terraform extension for Visual Studio Code also includes syntax highlighting and auto-completion support for provider-defined functions.

To learn how to develop your own provider-defined functions, refer to the Functions section of the Terraform Plugin Framework documentation and try it yourself with the new Implement a function tutorial, part of the Custom framework providers collection.

»Refactor across resource types

Refactoring code is a common practice for Terraform authors, whether it’s to break up a large configuration into multiple modules or simply to rename resources. Terraform provides two mechanisms to support refactoring operations while preserving the state of existing resources: the moved block introduced in Terraform 1.1 and the terraform state mv command. But there is another class of refactoring that involves changing the type of a resource. Changing the resource type previously required a multi-step operation to manually remove the resource from state without destroying it, update the code, and then re-import to the new resource type.

In Terraform 1.8, supported resources can be moved between resource types with a new, faster, and less error-prone method. Some use cases for this method include:

• Renaming a provider after an acquisition or rebrand
• Splitting a resource into more specific types
• API changes such as service renames or versioned resources
• Cross-provider moves

Providers can add support for this capability by declaring which resources can be refactored between types. An example moved block might look like this:

»Get started with Terraform 1.8

To learn more about these features and all of the enhancements in Terraform 1.8, review the full Terraform 1.8 changelog. To get started with HashiCorp Terraform:

• Download Terraform 1.8
• Sign up for a free Terraform Cloud account
• Read the Terraform 1.8 upgrade guide
• Get hands-on with tutorials at HashiCorp Developer

As always, this release wouldn't have been possible without the great community feedback we've received via GitHub issues and from our customers. Thank you!