[user5994461]

Ansible handles deletion just fine. Provisioning instances for example takes a number of instances, set to 0 to delete them. The more stable resources have a separate command to delete like ec2_vpc vs ec2_vpc_delete.

IMO The way terraform automatically/accidentally delete stuff is a major design flaw, not a feature to emulate. It's madness that it tries to auto nuke potentially a whole company just because it lost track of one resource identifier.

[zaphar]

    set to 0 to delete them

then I have a step in there that I will have to remove in a subsequent commit. The process as you describe it for a list of set of instances is:

1. commit a change that sets to 0

2. deploy change.

3. Make a new commit removing the step.

In Terraform it's just

1. Commit a change removing the resource.

2. Deploy

No cleanups that might be forgotten. No double commits for something that should just be 1.

Terraform doesn't "lose track" of an identifier. It's state file management is pretty robust and it has built in locking for the shared use case.

[gazoakley]

I'm not sure why you've had problems with Terraform trying to nuke things - I'd say the planning capability was one of its strong points. A quick glance at the plan will tell you what it needs to remove to put an environment in the expected state (and it's called out again in the destroy count summary at the end of then plan). Terraform doesn't "accidentally" delete things - it's doing it because you've told it they're not needed anymore.

[user5994461]

>> Terraform doesn't "accidentally" delete things - it's doing it because you've told it they're not needed anymore.

That's putting it backward to say the least. One never tells terraform that something is not needed anymore. One declares what is needed and terraform will find a way to get there by altering/creating/deleting stuff.

There is a review phase of course and it's very important because it might do anything. Anybody who's had to use terraform can attest that it is scary to run. Any slight error in configuration or state can be tremendously destructive.

[gazoakley]

>> There is a review phase of course and it's very important because it might do anything. Anybody who's had to use terraform can attest that it is scary to run.

This is no worse than Ansible - if for a set of EC2 instances the user "set to 0 to delete them" then Ansible will blindly do as requested and be just as destructive. On the other hand:

* Terraform does its best to enforce the recommended plan/apply workflow - the plan is always presented before any changes are made, and auto-approval is strongly discouraged.

* There are multiple options for review - do it there and then, or store the plan as an artefact and share with others for review.

* It doesn't matter when you run a stored plan - the plan is the set of changes that will be applied regardless of current state.

* The summary makes very clear if anything is going to be destroyed in bright red text.

Ansible offers some visibility of what it will do with dry runs, although it's not as complete - there's no way to guarantee it will do the same thing next time if changes have been made in the interim.