Resources - State Migration
Resources define the data types and API interactions required to create, update, and destroy infrastructure with a cloud vendor while the Terraform state stores mapping and metadata information for those remote objects. There are several reasons why a resource implementation needs to change: backend APIs Terraform interacts with will change overtime, or the current implementation might be incorrect or unmaintainable. Some of these changes may not be backward compatible and a migration is needed for resources provisioned in the wild with old schema configurations.
The mechanism that is used for state migrations changed between v0.11 and v0.12 of the SDK bundled with Terraform core. Be sure to choose the method that matches your Terraform dependency.
Terraform v0.12 SDK State Migrations
Note: This method of state migration does not work if the provider has a dependency on the Terraform v0.11 SDK. See the Terraform v0.11 SDK State Migrations section for details on using MigrateState
instead.
For this task provider developers should use a resource's SchemaVersion
and StateUpgraders
fields. Resources typically do not have these fields configured unless state migrations have been performed in the past.
When Terraform encounters a newer resource SchemaVersion
during planning, it will automatically migrate the state through each StateUpgrader
function until it matches the current SchemaVersion
.
State migrations performed with StateUpgraders
are compatible with the Terraform 0.11 runtime, if the provider still supports the Terraform 0.11 protocol. Additional MigrateState
implementation is not necessary and any existing MigrateState
implementations do not need to be converted to StateUpgraders
.
The general overview of this process is:
- Create a new function that copies the existing
schema.Resource
, but only includes theSchema
field. Terraform needs the type information of each attribute in the previous schema version to successfully migrate the state. - Change the existing resource
Schema
as necessary. - If the
SchemaVersion
field for the resource is already defined, increase its value by one. IfSchemaVersion
is not defined for the resource, addSchemaVersion: 1
to the resource (resources default toSchemaVersion: 0
if undefined). - Implement the
StateUpgraders
field for the resource, which is a list ofStateUpgrade
. The newStateUpgrade
should be configured with the following:Type
set toCoreConfigSchema().ImpliedType()
of the savedschema.Resource
function above.Upgrade
set to a function that modifies the attribute(s) appropriately for the migration.Version
set to the version of the schema before this migration. If no previous state migrations were performed, this should be set to0
.
For example, with a resource without previous state migrations:
Say the instance
resource API now requires the name
attribute to end with a period "."
To unit test this migration, the following can be written:
Terraform v0.11 SDK State Migrations
NOTE: This method of state migration does not work if the provider has a dependency on the Terraform v0.12 SDK. See the Terraform v0.12 SDK State Migrations section for details on using StateUpgraders
instead.
For this task provider developers should use a resource's SchemaVersion
and MigrateState
function. Resources do not have these options set on first implementation, the SchemaVersion
defaults to 0
.
Say the instance
resource API now requires the name
attribute to end with a period "."
To trigger the migration we set the SchemaVersion
to 1
. When Terraform saves state it also sets the SchemaVersion
at the time, that way when differences are calculated, if the saved SchemaVersion
is less than what the Resource is currently set to, the state is run through the MigrateState
function.
Although not required, it's a good idea to break the migration function up into version jumps. As the provider developer you will have to account for migrations that are larger than one version upgrade, using the switch/case pattern above will allow you to create codepaths for states coming from all the versions of state in the wild. Please be careful to allow all legacy versions to migrate to the latest schema. Consider the code now where the name
attribute has moved to an attribute called fqdn
.
The fallthrough allows a very old state to move from 0 to 1 and now to 2. Sometimes state migrations are more complicated, and requires making API calls, to allow this the configured meta any
is also passed to the MigrateState
function.