Design state-move based refactoring support

[danieldreier]

Terraform Core 1.1 will add a config_driven_move experiment, which seeks to help users update resource names in state when they rename or move resources. The syntax will look like (from Core tests):

moved {
  from = module.a
  to   = module.b
}

The need for this is that when users use a gitops workflow, they will tend to rename issues in terraform configs, and that gets out of sync with their terraform state. In order to keep the two in sync, users generally write long bash scripts that automate renaming things in state, and then must run these against dev/state/prod environments immediately prior to running Terraform.

This is a design ticket. The scope of this issue is to decide whether to expose this functionality to CDK for Terraform to help users update state when they rename resources, to propose an expected UX, and to plan the implementation as concrete tasks in a future release.

[jsteinich]

I don't know much about the core feature, but it sounds like something that we absolutely will want to support. Developers are accustomed to refactoring code and are likely to encounter issues when doing so.

A manual specification is a good first step, but perhaps an automated approach could then be added. One idea is to mimic how git detects moved files.

This seems very similar to #1091

[apparentlymart]

We have some draft docs for this new mechanism, in case that's helpful for thinking about how to (and whether to) expose something comparable in CDK-based programs.

We don't have any current plans to try to detect moves heuristically, except for one specific situation which Terraform has supported for a long time: if you have count set and there's an existing object without any instance key then Terraform will infer a move to instance key zero, and vice-versa. We've re-implemented that existing special-case behavior in terms of the new mechanism so that Terraform can give the same explicit feedback during planning about what it's going to do.

Other heuristics are probably possible too, but we intend to be conservative at first because that means no change in existing behavior for anyone who doesn't add moved blocks to their configuration, which is true to our v1.0 compatibility promises. However, CDK for Terraform is not constrained by those promises, so if you'd like to experiment with heuristic approaches here then that could be interesting! (I'm not sure if the cdktf tool will have enough information itself to try such inferences today though, since it would need to compare configuration with state in order to do so and only Terraform Core knows how to fully evaluate a configuration to determine its proposed new state.)

[xiehan]

Duplicate of #1292

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.