Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not very familiar with Azure anymore, but AWS also offers deletion protection on RDS and other services. This forces a two-phase operation with Terraform. You must first apply configuration to remove the deletion protection, then in the second phase you may delete the RDS instance.

Unfortunately, I've never been able to get much mileage from the Terraform prevent_destroy lifecycle option because it can't be set from a variable. Most of my configurations use a module and pass different variable values per each environment. I'd want the lifecycle flag in production, but maybe not dev.



I'd also think about whether you actually don't want this in dev. In the past, it's been helpful to have stage and dev environments be as close to production as possible, quirks with lifecycle and all.


Yes, Azure has a similar thing for resources where you can set a "CanNotDelete" lock on one. You have to delete the lock before you can delete the resource.


> Unfortunately, I've never been able to get much mileage from the Terraform prevent_destroy lifecycle option because it can't be set from a variable

There is a trick around this. Code 2 mostly identical resources, one with prevent_destroy true and the other with prevent_destroy false. Give both resources a count. You can make the count dependent on interpolation. And the count can be zero. So depending on the interpolation result you have resource(s) with prevent_destroy or without. For the "wrong" ones you just create 0 of them.

https://stackoverflow.com/questions/53727357/terraform-how-t...

https://stackoverflow.com/questions/53744441/how-to-refer-to...


That just means that enabling `prevent_destroy` later on will a) destroy the resource b) create a new resource with a different name and `prevent_destroy` enabled.

Plus the combinatorial explosion of all possible conditions.

Not a good trick.


Why would I want to enable it later? When I deploy production they ave enable_destroy. It's the same resource all the time and it must not be destroyed.

When I want to deploy a test system the resource can be destroyed after I am done.

Of course this is not really elegant code. It violates DRY, I need to make sure that my test resources have identical configuration as my production resources, except this one attribute.

Maybe your use case is different. I never change the prevent_destroy attribute during the lifetime of the resource.


That's a "trick" I saw in the wild in several community TF modules but as the other commenter says, it's not that clever because once you want to change that specific parameter, you will trigger a complete destroy+recreate action which as you might imagine is not that good in real production.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: