Terragrunt: Migrate state if directory is changed

[bfleming-ciena]

You know how terraform handles moving directories around... The next time you run terraform it detects that and asks if you want to migrate or copy your state to a new file.

When I'm using terragrunt, and sourcing one project, that behavior seems to have been lost.

If I move the directory and run terragrunt, the state is not found and it tries to create your objects.

[ldormoy]

In the meantime, is there a way to achieve this using "terragrunt state" commands?

The only way I found (using a S3 backend) is to directly mv the file using the aws CLI.

[sclausson]

Is there any workaround for this beyond moving the default.state file to the new backend path as @ldormoy suggests?

[kannan-ak]

+1

Just faced this issue today. Terragrunt creates a new statefile when the directories are changed. Would be helpful if terragrunt-cache can keep a reference of the statefile by using the configs it passing.

[FernandoMiguel]

@ldormoy moving it in s3 is not enough as the path is also in the statefile

[steve-a-jones]

Running in to this same thing -- what is the recommended pattern here? Experimenting with different directory structures but have live resources that I don't want to accidentally duplicate..

[yorinasub17]

It would be nice to have a solution to this, but this means terragrunt needs to do its own state tracking and that is a significant deviation from terragrunt as a terraform wrapper. We've already run into multiple unexpected issues with terragrunt doing state tracking of the files in .terragrunt-cache, and having an additional layer of state tracking will further complicate the problem.

Since this isn't really an issue we have internally at Gruntwork (our patterns are more or less solidified such that we rarely do directory experimentation), we are unlikely to tackle on this any time soon. That said, if anyone wants to take a crack at this, we'd be happy to help out with design discussions/pointers/PR reviews. Next step would be to submit an RFC with a proposal of how the state tracking will work.

As far as workarounds go, check out https://community.gruntwork.io/t/terraform-state-is-messed-up-after-moving-folders/448/4?u=yoriy for a pattern based on terragrunt state commands.

[steve-a-jones]

@yorinasub17 Appreciate the response! The workaround above worked out for me -- this is exactly what i was looking for.

[rgarrigue]

I tried the workaround for a simple folder renaming case, like this

terragrunt state pull > temporary_state.json
cd ..
git mv old_bad_naming new_shiny_naming
cd new_shiny_naming
terragrunt state push temporary_state.json

The push failed on a Failed to refresh destination state: state data in S3 does not have the expected content. Any idea ?

@yorinasub17 without going in the complexity of state tracking to be able to do some auto remediation on apply, would it be possible to come up with a terragrunt mv command doing the above, maybe with a couple of safeguard like plan before & after, revert if different ?

[yorinasub17]

The push failed on a Failed to refresh destination state: state data in S3 does not have the expected content. Any idea ?

This usually occurs when the digest does not match in dynamodb, which is typically caused by stale state locks. If you know for sure that nothing is touching the state, you can delete the corresponding entry in dynamodb to clear the lock.

without going in the complexity of state tracking to be able to do some auto remediation on apply, would it be possible to come up with a terragrunt mv command doing the above, maybe with a couple of safeguard like plan before & after, revert if different ?

I think this would work, but I don't quite have time at the moment to think through all the implications to make a call for sure (e.g., what happens when there is an error in the process? Should there be support for rollbacks? Would this support changes that affect relative paths in the terragrunt.hcl file?). As mentioned above, an RFC with the exact details of how this might work, or if the implementation is simple, a direct PR would be highly appreciated!