5 ms·
If Terraform is stateless, how does it know what it needs to / can delete? You'll either have to: - Move the state management elsewhere, and invoke different
by aayjaychan 4y ago
If Terraform is stateless, how does it know what it needs to / can delete?
You'll either have to:
- Move the state management elsewhere, and invoke different commands depends on what and how resources are changed. This will make automation difficult, and doesn't solve the problem.
- Make Terraform assume that everything it sees is under its management, deleting everything not defined in the current configuration. This will make Terraform hard to adopt in an environment with existing infrastructure.
- rwiggins 4y agoPresumably you'd encode removed resources somehow in the DSL. Maybe a flag like `removed = true`.
- NovemberWhiskey 4y agoCongratulations; your state management is now part of your code.
- GeneralMayhem 4y agoAnd that would be a huge improvement! Code has history. Code can be managed with sed and grep. Code can be generated by tools I write myself. Adding a tombstone for deletion, or a formerly-known-as tag for renames, is only "state" in the way that reserved tag numbers in protocol buffers are "state". It is a little annoying to have to do, and it creates clutter that you eventually have to go back and clean up, but neither of those is a dealbreaker, and in the meantime it solves the second-biggest problem with Terraform, which is the inscrutability of what it actually thinks it's doing when it comes up with a plan you don't expect. (The biggest problem is how ridiculously inexpressive HCL is as a language.)
- InvertedRhodium 4y agoThe best practices for terraform is to use a versioned state store, which covers history. Under the hood, the terraform file is just JSON, so sed, grep, jq etc can be used to manipulate it (as well as any other tools you'd care to write).
- aayjaychan 4y agoI'll consider this a variation on moving state elsewhere. Now you have to keep the deleted resource forever. Or keep track of which environments the version with the removal directive is deployed to, or risk having orphaned resources in different environments.
- ratww 4y ago> Now you have to keep the deleted resource forever Not really. In every other system you can remove tombstones after a while.
- Too 4y agoNot much different from how DB migration scripts are managed when using ORMs.
- rwiggins 4y agoFair enough. It does at least let you continue to use the same commands/tooling. But anyway, agreed, I think the stateful status quo is the way to go.
- GeneralMayhem 4y agoIt's not that bad as long as you have a reasonable deployment process. If you can't rely on your production state being fairly up to date relative to the Terraform definition, then you've got bigger problems than dealing with TF statefulness. If you know that TF changes are guaranteed to be deployed within X days of writing them (e.g., with something like Atlantis, or even a weekly deployment schedule), then you can put a date in the comment of when the tombstone was added, and clean it up either automatically after X days or occasionally in a semi-automated sweep.
- aayjaychan 4y agoI agree having production updated frequently is ideal, but sometimes we don't get to choose when things are deployed when working with external clients. I'm glad Terraform doesn't dictate the workflow, so that we can fix one thing at a time.
- cmeacham98 4y agoMost (all?) cloud providers support some form of tagging. Have like a `managed-by=terraform` tag, and assume everything with that tag is Terraform managed.
- pojzon 4y agoIm gonna ignore the fact that moving state to other place completwly misses article point, but: Two Users create exactly the same resource with the same tags. Which one should be removed by Terraform? Now either way lets ignore that. You want to refresh infrastructure to know what to do. Without the state you have to go through EVERY API CALL on every service even those you did not create to be able to determine the whole state of the infrastructure which would be super super long action. Without dependencies you would also have to maintain and build dependency tree EVERY TIME you would try to apply infra.
- cheradenine_uk 4y agoI don't believe it misses the article's point - I think he's asking the valid question "if the target system has the ability to to store all the required state in order to understand mappings between what I want and what I have, why do we need additional state files which always seem to be wrong" And a good answer might be "all providers don't have that capability" and/or "providers can't efficiently answer questions about that, such as 'find me all things with this configuration tag'. In your example, those two users wouldn't have the same tags, because you'd arrange it so that they didn't - either by user or a resource grouping based on the configuration itself. This is the choice made by some other tooling, for better or worse.
- psanford 4y agoThere are a lot of resources in AWS that don't support tags.
- scapecast 4y agoDo you have a few examples?