State Upgrade
A resource schema captures the structure and types of the resource state. Any state data that does not conform to the resource schema will generate errors or may not be persisted properly. Over time, it may be necessary for resources to make breaking changes to their schemas, such as changing an attribute type. Terraform supports versioning of these resource schemas and the current version is saved into the Terraform state. When the provider advertises a newer schema version, Terraform will call back to the provider to attempt to upgrade from the saved schema version to the one advertised. This operation is performed prior to planning, but with a configured provider.
Some versions of Terraform CLI will also request state upgrades even when the current schema version matches the state version. The framework will automatically handle this request.
State Upgrade Process
- When generating a plan, Terraform CLI will request the current resource schema, which contains a version.
- If Terraform CLI detects that an existing state with its saved version does not match the current version, Terraform CLI will request a state upgrade from the provider with the prior state version and expecting the state to match the current version.
- The framework will check the resource to see if it defines state upgrade support:
- If no state upgrade support is defined, an error diagnostic is returned.
- If state upgrade support is defined, but not for the requested prior state version, an error diagnostic is returned.
- If state upgrade support is defined and has an implementation for the requested prior state version, the provider defined implementation is executed.
Implementing State Upgrade Support
Ensure the schema.Schema
type Version
field for the resource.Resource
is greater than 0
, then implement the resource.ResourceWithStateUpgrade
interface for the resource.Resource
. Conventionally the version is incremented by 1
for each state upgrade.
This example shows a Resource
with the necessary StateUpgrade
method to implement the ResourceWithStateUpgrade
interface:
Each resource.StateUpgrader
implementation is expected to wholly upgrade the resource state from the prior version to the current version. The framework does not iterate through intermediate version implementations as incrementing versions by 1 is only conventional and not required.
All state data must be populated in the resource.UpgradeStateResponse
. The framework does not copy any prior state data from the resource.UpgradeStateRequest
.
There are two approaches to implementing the provider logic for state upgrades in StateUpgrader
. The recommended approach is defining the prior schema matching the resource state, which allows for prior state access similar to other parts of the framework. The second, more advanced, approach is accessing the prior resource state using lower level data handlers.
StateUpgrader With PriorSchema
Implement the StateUpgrader
type PriorSchema
field to enable the framework to populate the resource.UpgradeStateRequest
type State
field for the provider defined state upgrade logic. Access the request State
using methods such as Get()
or GetAttribute()
. Write the resource.UpgradeStateResponse
type State
field using methods such as Set()
or SetAttribute()
.
This example shows a resource that changes the type for two attributes, using the PriorSchema
approach:
StateUpgrader Without PriorSchema
Read prior state data from the resource.UpgradeStateRequest
type RawState
field. Write the resource.UpgradeStateResponse
type State
field using methods such as Set()
or SetAttribute()
, or for more advanced use cases, write the resource.UpgradeStateResponse
type DynamicValue
field.
This example shows a resource that changes the type for two attributes, using the RawState
approach for the request and DynamicValue
approach for the response:
Caveats
Note these caveats when implementing the UpgradeState
method:
- An error is returned if the response state contains unknown values. Set all attributes to either null or known values in the response.
- Any response errors will cause Terraform to keep the prior resource state.