prevent_destroy should let you succeed

Call me crazy, but I'm willing to call the current implementation of `prevent_destroy` a bug. Here is why: The current implementation of this flag prevents you from using it for 1/2 the use case. The net result is more frustration when trying to get Terraform to succeed instead of destroying your resources.. `prevent_destroy` adds to the frustration more than alleviating it. `prevent_destroy` is for these two primary use cases, right? 1) you don't want this resource to be deleted, and you want to see errors when TF tries to do that 2) you don't want this resource to be deleted, and you don't want to hear a peep out of TF - TF should skip over its usual prerogative to rm -rf on change. I see no reason why TF _must_ return an error when using `prevent_destroy` for the second use case, and in doing so, TF is completely ignoring my utterly clear directive to let me get work done. As a user, I end up feeling as though TF is wasting my time because I am focused on simple end goals which I am unable to attain while I spin my wheels begging TF to create more resources without destroying what exists. You might say the user should update their plan to not be in conflict, and I would agree that is what you want to do in most cases.. but, honestly, that is not always the right solution for the situation at hand when using a tool like TF for the real-world. I believe in empowering users, and the current implementation of this flag prevents sensible use of the tool.

Posted by ketzacoatl on Nov 12, 2015, 8:11 AM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0