How would that result in more API calls than Terraform with state? When creating a plan, Terraform does already compare stored resource state and actual resource state, which does require doing API requests for each resource.

Terraform also needs to detect when a resource is removed from a template. Having a state file makes this easy (if something is in the state file and not the template, delete it); otherwise, you have to scan your whole infrastructure (and still risk deleting something that was never managed by terraform in the first place).

In your inner dev loop, set -refresh=false, it’s a much nicer experience.

Terraform already does a three way reconciliation at plan/apply time. It checks declared state (your code), known state (your statefile), and current state (api calls to your providers).

If you want to see this, just make a terraform apply. After it completes, go change something directly in your cloud provider and run another plan. The top section of your plan will highlight the changes that Terraform found remotely that don't match existing state.

So all this would do is remove known state, so you could do a 2-way reconciliation instead of a 3-way reconciliation. You would compare current-state with declared state. This is how Kubernetes works. But to be fair, Kubernetes actually works in a slightly more controlled environment than Terraform.

Thanks for letting me know.

What an absolutely bone-headed idea. That gives you the worst of both worlds (I guess they’d argue it’s the best instead).

I guess that’s my mistake for assuming Terraform wouldn’t have an extra reason for me to hate it without making something up.