> You could also try using the count and for_each meta-arguments, but there's only so much you can do until complexity hits you in the head. And let's be honest, if something is called a "meta-argument", it's probably not a good idea.
Let’s actually be honest: here’s the workable solution -built into the language- to the problem you’re describing and you’re waving it away to justify whatever hack it is we’re about to be presented with.
> Besides the practical advantages of not having to modify .tf files every time someone needs a new bucket, this approach also completely detaches the concept of a desired state with the concept of an actual state.
Yeah, who wanted their infrastructure in version control anyway.
But seriously, if you want a new bucket without _all the hassle_ of using Terraform, just use the CDK or maybe even a CLI one-liner ?
The built-in way to do almost exactly, afaict, what's presented here is workspaces. Config once, multiple states for multiple environments. (Shared config via outputs from remote state in another project/stack, it is conceptually separate after all.)
Tools like Atlantis understand workspaces and can apply changes across multiple environments as part of automated infrastructure management.
Last time I had to edit terraform state 1) it didn't work (trying to downgrade to an older version of the state file after a newer version of terraform modified it) and 2) was more work than recreating the environment from scratch.
The overwhelming majority of uses for state surgery are break glass hacks for other issues, the fact people had to resort to it so frequently was a bug and something we were working hard to fix. The one you called out was (hopefully) addressed by having a stable schema, or at least one that could be read by newer and older versions in a consistent way, since (irrc) v0.14. Config-driven moves (`moved` statements in HCL) was a big one, especially for refactoring into or between modules. The recent import functionality is another in that long line. Some of the historical version upgrade specific issues we had to retrospectively address so they were more akin to guided workflows than core changes, and so they only existed in Terraform Cloud (though not paid-for features last I knew).
I'm sure we didn't get every single use case solved. But I'd recommend to everyone that if they find themselves reaching for a state command to double check there isn't now a better way. If there isn't a better way, it's worth making sure someone on the Terraform team is aware of that fact.
Let’s actually be honest: here’s the workable solution -built into the language- to the problem you’re describing and you’re waving it away to justify whatever hack it is we’re about to be presented with.