311–320 of 329 posts
Not true since Terraform 1.1 introduced moved blocks : https://www.terraform.io/language/modules/develop/refactorin...
Earlier quoted context omitted.
Next question: what if your database is managed by a separate team in the same account? Just delete it eh?
Yes. The tool warned you it would do this during the plan phase.
The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…
I think the trade offs of a stateless terraform would be favored by many
I respectfully disagree. If TF was stateless, you'd have to manage situations by hand that involve changing the idempotency key, such as the name of a VM. You'd also have to manage situations by hand where a resource is removed from the config. The whole point of TF is that it has state and doesn't require workarounds for these scenarios. Yes, you have to maintain state, but the state problems usually come from buggy…
I'll play devil's advocate (because I understand the need for a state): What if terraform was able to perform a complete audit of your environment for each provider and say "this is what you've got, mate", then give you options for each resource: 1. Accept (turns it into terraform code) 2. Reject (removes the resource) Taken further, this idea effectively means that manually creating something like EKS could be a way…
Earlier quoted context omitted.
Yes. The tool warned you it would do this during the plan phase.
This is absolutely the worst design for a tool imaginable. Any tooling fit for purpose must make peace with the fact that one team, and thus application of a tool, do not own an entire account.
Earlier quoted context omitted.
That does not seem problematic with modern APIs and concurrency. Two sources of truth is highly problematic
But it is problematic when you deal with larger infrastructures due to rate limits.
Earlier quoted context omitted.
But it is problematic when you deal with larger infrastructures due to rate limits.
I can’t imagine you would ever hit a rate limit, how often are you deploying large sums of infrastructure? For me it’s maybe a couple times a day and the surface area is small
If I have 3k machines running in an autoscaling group I think it would be ridiculous to have to hit each one of those with API calls to try and infer which were or weren't part of my state. Building a simple high availability VPC is about 72 resources just by itself.
I don't think people advocating for "the cloud is the state" realize how big even trivial environments can get- let alone complex ones.
Earlier quoted context omitted.
That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?
I'm amused that you think "cloud providers have bad APIs" is a bold claim instead of the default state of things. Things as basic as IAM Groups in AWS aren't taggable: https://registry.terraform.io/providers/hashicorp/aws/latest... IAM Users are taggable, but to get the tags on a given user, you must request them one user at a time from a known list of users. The "List all users" call doesn't return their tags. Obvio…
Cloud providers having bad APIs is definitely the default state.