Much like application software releases can have accompanying database migrations to massage tables and schemas to match with the new application code, I think it would be nice to have a feature like this for terraform. Here’s the issue:
Sometimes when I make an update to a module, I make a change to an underlying resource that requires a state mv operation to be done before the first apply is done with the upgraded module. I (or someone else that paid attention to the README) have to manually run a terraform state mv foo bar before the apply or incur a possible outage because a resource will be destroyed and recreated. If there could be an accompanying “migration” definition that could trigger certain actions so that the state mv command(s) would be automatically run along with the apply, this would make life easier :).
Has anyone else had this thought? Implementation ideas?
It sounds like you’re talking about the same sort of thing as we were discussing a while back in this issue:
More recently, I’ve been referring to this space of problems using the more catchy title “everything is a plan”, which is to say that any operation you can do with Terraform should be driven by the same workflow of altering the configuration in some way and then creating and applying a plan.
I’ve not had a chance to think much about it lately because our attention has been on other things, but I’d still like to return to this eventually and explore the problem space a bit more to see what might work to eliminate all of the random extra operations that aren’t part of the main Terraform workflow today, which includes everything terraform state ... subcommands do but might also include terraform import, the -target option, etc… basically, to try to incorporate anything that might today cause you to run any thing other than terraform plan and terraform apply without arguments in order to make a change to remote objects or to the state.