Deprecations, Removals, and Renames
Terraform is trusted for managing many facets of infrastructure across many organizations. Part of that trust is due to consistent versioning guidelines and setting expectations for various levels of upgrades. Ensuring backwards compatibility for all patch and minor releases, potentially in concert with any upcoming major changes, is recommended and supported by the Terraform development framework. This allows operators to iteratively update their Terraform configurations rather than require massive refactoring.
This guide is designed to walk through various scenarios where existing Terraform functionality requires future removal, while maintaining backwards compatibility. Further information about the versioning terminology (e.g. MAJOR
.MINOR
.PATCH
) in this guide can be found in the versioning guidelines documentation.
NOTE: Removals should only ever occur in MAJOR
version upgrades.
NOTE: This documentation references usage of the DeprecationMessage
field, please see the schema documentation for more detailed guidance on how to structure warning messages and when those warnings will be raised to practitioners.
Table of Contents
- Provider Attribute Removal
- Provider Attribute Rename
- Provider Data Source or Resource Removal
- Provider Data Source or Resource Rename
Provider Attribute Removal
The recommended process for removing an attribute from a data source or resource in a provider is as follows:
- Add a
DeprecationMessage
in the attribute schema definition. Set this field to a practitioner actionable message such as"Remove this attribute's configuration as it's no longer in use and the attribute will be removed in the next major version of the provider."
- Ensure the changelog has an entry noting the deprecation.
- Release a
MINOR
version with the deprecation. - In the next
MAJOR
version, remove all code associated with the attribute including the schema definition. - Ensure the changelog has an entry noting the removal.
- Release the
MAJOR
version.
Provider Attribute Rename
When renaming an attribute from one name to another, it is important to keep backwards compatibility with both existing Terraform configurations and the Terraform state while operators migrate. To accomplish this, there will be some duplicated logic to support both attributes until the next MAJOR
release. Once both attributes are appropriately handled, the process for deprecating and removing the old attribute is the same as noted in the Provider Attribute Removal section.
The procedure for renaming an attribute depends on what type of attribute it is:
Renaming a Required Attribute
NOTE: If the schema definition does not contain Optional
or Required
, see the Renaming a Computed Attribute section instead. If the schema definition contains Optional
instead of Required
, see the Renaming an Optional Attribute section.
Required attributes are also referred to as required "arguments" throughout the Terraform documentation.
In general, the procedure here does two things:
- Prevents the operator from needing to define two attributes with the same value.
- Allows the operator to migrate the configuration to the new attribute at the same time requiring that any other references only work with the new attribute. This is to prevent a situation with Terraform showing a difference when the existing attribute is configured, but the new attribute is saved into the Terraform state. For example, in
terraform plan
output format:
The recommended process is as follows:
- Replace
Required: true
withOptional: true
in the existing attribute schema definition. - Replace
Required
withOptional
in the existing attribute documentation. - Duplicate the schema definition of the existing attribute, renaming one of them with the new attribute name.
- Duplicate the documentation of the existing attribute, renaming one of them with the new attribute name.
- Add a
DeprecationMessage
to the schema definition of the existing (now the "old") attribute, noting to use the new attribute in the message. - Add
**Deprecated**
to the documentation of the existing (now the "old") attribute, noting to use the new attribute. - Add a note to the documentation that either the existing (now the "old") attribute or new attribute must be configured.
- Add the type-specific validator
{type}validator.ExactlyOneOf
to the schema definition of the new attribute, with a path expression matching the old attribute. This will ensure at least one of the attributes is configured, but present an error to the operator if both are configured at the same time. For example, an attribute of type string would use thestringvalidator.ExactlyOneOf
validator. - Add conditional logic in the
Create
andUpdate
functions of the data source or resource to handle both attributes. Generally, this involves using{type}.IsNull()
. - Follow the rest of the procedures in the Provider Attribute Removal section. When the old attribute is removed, update the schema definition and documentation of the new attribute back to
Required
, and remove the{type}validator.ExactlyOneOf
validator.
Example Renaming of a Required Attribute
Given this sample resource:
In order to support renaming existing_attribute
to new_attribute
, this sample can be written as the following to support both attributes simultaneously until the existing_attribute
is removed:
When the existing_attribute
is ready for removal, then this can be written as:
Renaming an Optional Attribute
NOTE: If the schema definition does not contain Optional
or Required
, see the Renaming a Computed Attribute section instead. If the schema definition contains Required
instead of Optional
, see the Renaming a Required Attribute section.
Optional attributes are also referred to as optional "arguments" throughout the Terraform documentation.
In general, the procedure here allows the operator to migrate the configuration to the new attribute at the same time requiring that any other references only work with the new attribute. This is to prevent a situation with Terraform showing a difference when the existing attribute is configured, but the new attribute is saved into the Terraform state. For example, in terraform plan
output format:
The recommended process is as follows:
- Duplicate the schema definition of the existing attribute, renaming one of them with the new attribute name.
- Duplicate the documentation of the existing attribute, renaming one of them with the new attribute name.
- Add a
DeprecationMessage
to the schema definition of the existing (now the "old") attribute, noting to use the new attribute in the message. - Add
**Deprecated**
to the documentation of the existing (now the "old") attribute, noting to use the new attribute. - Add the type-specific validator
{type}validator.ExactlyOneOf
to the schema definition of the new attribute, with a path expression matching the old attribute. This will ensure at least one of the attributes is configured, but present an error to the operator if both are configured at the same time. For example, an attribute of type string would use thestringvalidator.ExactlyOneOf
validator. - Add conditional logic in the
Create
andUpdate
functions of the data source or resource to handle both attributes. Generally, this involves using{type}.IsNull()
. - Follow the rest of the procedures in the Provider Attribute Removal section. When the old attribute is removed, remove the
{type}validator.ExactlyOneOf
validator.
Example Renaming of an Optional Attribute
Given this sample resource:
In order to support renaming existing_attribute
to new_attribute
, this sample can be written as the following to support both attributes simultaneously until the existing_attribute
is removed:
When the existing_attribute
is ready for removal, then this can be written as:
Renaming a Computed Attribute
NOTE: If the schema definition contains Optional
see the Renaming an Optional Attribute section instead. If the schema definition contains Required
see the Renaming a Required Attribute section instead.
The recommended process is as follows:
- Duplicate the schema definition of the existing attribute, renaming one of them with the new attribute name.
- Duplicate the documentation of the existing attribute, renaming one of them with the new attribute name.
- Add a
DeprecationMessage
to the schema definition of the existing (now the "old") attribute, noting to use the new attribute in the message. - Add
**Deprecated**
to the documentation of the existing (now the "old") attribute, noting to use the new attribute. - Set both attributes in the Terraform state in the
Create
,Update
, andRead
functions of the resource (Read
only for data source). - Follow the rest of the procedures in the Provider Attribute Removal section.
Example Renaming of a Computed Attribute
Given this sample resource:
In order to support renaming existing_attribute
to new_attribute
, this sample can be written as the following to support both attributes simultaneously until the existing_attribute
is removed:
When the existing_attribute
is ready for removal, then this can be written as:
Provider Data Source or Resource Removal
The recommended process for removing a data source or resource from a provider is as follows:
- Add a
DeprecationMessage
in the data source or resource schema definition. After an operator upgrades to this version, they will be shown a warning with the message provided when using the deprecated data source or resource, but the Terraform run will still complete. - Ensure the changelog has an entry noting the deprecation.
- Release a
MINOR
version with the deprecation. - In the next
MAJOR
version, remove all code associated with the deprecated data source or resource except for the schema and replace theCreate
,Read
,Update
, andDelete
functions to always return an error diagnostic. Remove the documentation sidebar link and update the resource or data source documentation page to include information about the removal and any potential migration information. After an operator upgrades to this version, they will be shown an error about the missing data source or resource. - Ensure the changelog has an entry noting the removal.
- Release the
MAJOR
version. - In the next
MAJOR
version, remove all code associated with the removed data source or resource. Remove the resource or data source documentation page. - Release the
MAJOR
version.
Example Resource Removal
Given this sample provider and resource:
In order to deprecate example_widget
, this sample can be written as:
To soft remove example_widget
with a friendly error message, this sample can be written as:
To remove example_widget
:
Provider Data Source or Resource Rename
When renaming a resource from one name to another, it is important to keep backwards compatibility with both existing Terraform configurations and the Terraform state while operators migrate. To accomplish this, there will be some duplicated logic to support both resources until the next MAJOR
release. Once both resources are appropriately handled, the process for deprecating and removing the old resource is the same as noted in the Provider Data Source or Resource Removal section.
The recommended process is as follows:
- Duplicate the code of the existing resource, renaming (and potentially modifying) functions as necessary.
- Duplicate the documentation of the existing resource, renaming (and potentially modifying) as necessary.
- Add a
DeprecationMessage
to the schema definition of the existing (now the "old") resource, noting to use the new resource in the message. - Add
~> This resource is deprecated and will be removed in the next major version
to the documentation of the existing (now the "old") resource, noting to use the new resource. - Add the new resource to the provider
Resources
function - Follow the rest of the procedures in the Provider Data Source or Resource Removal section.
Example Resource Renaming
Given this sample provider and resource:
In order to support renaming example_existing_widget
to example_new_widget
, this sample can be written as the following to support both resources simultaneously until the example_existing_widget
resource is removed:
To soft remove example_existing_widget
with a friendly error message:
To remove example_existing_widget
: