What happens if you forget the lifecycle annotations or put them in the wrong place or you accidentally delete them? Last time I checked it was data loss, but that was a few years ago.
The same as in any other language when what you wrote was not what you intended? Sorry, I’m really confused what your complaint here is or how you’d prefer it to work. If you make a sensitive resource managed by any kind of IAC, of course the IAC can destroy it in a manner that would result in irretrievable data loss. The language has for forever put semantics in place to prevent that, and I’m not sure as a power user I’d want it any other way, I’m explicit with what I want it to do and dont want it making crazy assumptions that I didnt write.
like, what happens if you forget to free a pointer in c? sorry for snark but there are an unbelievably numerous amount of things to complain about in tf, never heard this one.
> what happens if you forget to free a pointer in c?
Assuming you mean 'forget' to free malloc'd space referenced by at least one pointer, that's an easy one .. it's reclaimed by the OS when the process ends.
Whether that's a bad thing or not really depends on context - there are entire suites of interlocked processing pipelines built about the notion of allocating required resources, throughputing data, and terminating on completion - no free()'s
surely my salient point is recognized regardless of semantics, but thanks for the correction. To use another example in another post - what happens if you DROP TABLE in sql?
DROP TABLE is explicit. Inadvertently removing a line from a config file and having Postgres decide to automatically "clean up" that "unneeded table" would be a more apt analogy.
"What happens if I turn a table saw on and start breakdancing on it?"
Of course you're going to hurt yourself. If you didn't put lifecycle blocks on your production resources, you weren't organizationally mature enough to be using Terraform in production. Take an associate Terraform course, this specific topic is covered in it.
I'm not familiar with every lifecycle argument but I don't know of any that prevent resources being destroyed if they are removed from the tf file (what the parent was talking about). prevent_destroy, per docs, only applies as long as the resource is defined.
I think the only way to avoid accidentally destroying a resource is to refer to it somewhere else, like in a depends_on array. At least that would block the plan.
>I don't know of any that prevent resources being destroyed if they are removed from the tf file (what the parent was talking about).
Azure Locks (which you can also manage with Terraform), Open Policy Agent, Sentinel rules, etc. will prevent a destroy even if you remove the definition from your Terraform codebase. Again, if you're not operationally mature enough, the problem isn't the tool, it's you.
"Operationally mature" is code here for "the gun starts out loaded and pointed at your foot". It's fine to point out that that's a suboptimal design for a tool.
>Operationally mature" is code here for "the gun starts out loaded and pointed at your foot"
No, it's code for "don't build a load bearing bridge if you don't understand structural engineering."
> It's fine to point out that that's a suboptimal design for a tool.
This isn't "suboptimal" though. If you delete a stored procedure in your RDBMS and it causes an outage, it's not because SQL/PostgreSQL is suboptimal. Similarly if you accidentally delete files from your file system, it's not because file systems are "suboptimal". It's because you weren't operationally mature enough to have proper testing and backups in place.
Defaults matter. I don't know how else to express that a system which fails safe in the face of fallible humans is strictly better, all else being equal, than the alternative.
It doesn't just "get deleted," by default it prompts and warns the user that there is a deletion planned, and the user must manually confirm the deletion. There is no issue.
