Hacker News Reader

Comment by bwship | Hacker News Reader

We had the same issue with DynamoDB, that Terraform is all to happy to delete a table it deems acceptable to delete. Which in 99 out of 100 cases is never the case. It is a very aggressive IaC tool.

View on HN

It's a very powerful tool. Just like any other (well designed) tool, it's only going to do what the operator tells it to do.

Terraform will never delete something you don't tell it to.

> Terraform will never delete something you don't tell it to.

Not necessarily. With some providers (e.g. Azure), Terraform will fail to recognize automated behind-the-scenes changes and try to revert them, causing serious breakage. This is why the "ignore_changes" meta-argument exists. See https://itnext.io/how-and-when-to-ignore-lifecycle-changes-i...

Instances like this is where CDK is superior to Terraform imho. There are many resources which are difficult (or impossible) to delete or modify once created with CDK, and for good reason. Secrets also fall into this category.

We also ran into issues with the CDK, that it errors out if the resource already exists and was not created with the CDK. We end up using Ansible for the DynamoDB. Though Ansible can't deploy to LocalStack. So, it seems that we are still in a world where you have to use a couple different IaC tools depending on the needs.

What's the use-case for creating resources outside of--but also defining them in--CDK in this case? That's generally an anti-pattern.

It's actually not an anti-pattern. CDK provides many methods (e.g. `StringParameter.valueForStringParameter`) for accessing deployed resources from other stacks, or those deployed by other tools or manually. IaC can get in the way or that, but it's not forbidden, nor discouraged.

You could tag everything you care about with lifecycle rules to not delete but it'd be nicer if they were the default for certain resources.

Reply on news.ycombinator.com