Enhance support for remote backends in state subsystem

[ablackrw]

Current Terraform Version

Terraform v0.12.17
+ provider.aws v2.39.0

Use-cases

The primary use case is the relocation of resources from one project to another when the target project makes use of a remote backend. I have a need to perform this relocation, as I am in the process of restructuring our terraform projects to provide a more maintainable layout. In doing so, I am combining several projects into a single module-based 'master' project.

Attempted Solutions

The naive solution would be to run one of the following commands:

• terraform state mv -state=/path/to/source -state-out=/path/to/destination <resource> <resource>
• terraform state mv -state=/path/to/source/config.tf -state-out=/path/to/destination/config.tf <resource> <resource>
  In both cases, /path/to/source and /path/to/destination contain a terraform project, with the terraform object definition residing in the config.tf file within the directory. Both commands result in a usage message, as the target specified isn't a .tfstate file.

The next solution would be to execute something resembling the following commands:

1. cd /path/to/source
2. terraform state mv -state-out=../export.tfstate <resource> <resource>
3. cd ../destination
4. terraform state mv -state=../export.tfstate <resource> <resource>
   However, the second command will fail with the following error:

Error: Invalid target address

Cannot move to <resource>: there is already a resource
instance at that address in the current state.

The workaround for this error is as follows:

1. terraform state pull > raw.tfstate
2. terraform state mv -state=../export.tfstate -state-out=raw.tfstate <resource> <resource>
3. terraform state push raw.tfstate

Proposal

I see a couple possible changes that could be made to make the process of moving resources easier. The first change would be the addition of a -state-in switch to the terraform state mv command. This would be analogous to the -state-out switch that allows the command to write to a different statefile than the default state file, except it identifies the source file rather than the destination file. This would change the second sequence of commands to

1. cd source
2. terraform state mv -state-out=../export.tfstate <resource> <resource>
3. cd ../destination
4. terraform state mv -state-in=../export.tfstate <resource> <resource>

An alternative to this change would be to alter the behavior of the -state switch as above, but this would result in unexpected behavior if you were attempting to modify the contents of a .tfstate file from a directory that contained a terraform project.

The second change would be to update the file handling logic in the terraform state subsystem such that it will accept directory references in addition to paths to a .tfstate file. If a directory reference was provided, the subsystem would attempt to process said directory using the same logic currently used to select the default state file for the current working directory.

References

• state mv -state-out=... module.source module.destination doesn't work with s3 backed remote states #21796