Hacker News Reader

Comment by mitchellh | Hacker News Reader

Yes, but CloudFormation doesn't have Terraform's concept of an "execution plan"[1], which tells you what Terraform will do, before it does it. It is very easy with CloudFormation (especially as they get larger and more complex) to run into cases where CloudFormation unexpectedly destroys and recreates a resource, something that would never happen in Terraform because you would see it before it happened in the plan.

There are more comparisons to CF here: http://www.terraform.io/intro/vs/cloudformation.html

[1]: http://www.terraform.io/docs/commands/plan.html

View on HN

Agreed, having to dig through the AWS documentation to see what whether updating a particular value requires replacing the resource it applies to is tedious and error prone.

Another things that excites me about separating the plan from the execution is that I can periodically run `terraform plan` to check for configuration drift without risking making a change. I've been bitten by the following:

1) Someone creates an ASG with the desired number of instances set to 1 via CloudFormation 2) Later, they increase the desired number of instances, e.g. to 5, via the EC2 console or API rather than CloudFormation 3) I come along and apply an update to the stack via CloudFormation. This resets their ASG to 1 instance, terminating the other 4.

If anyone from AWS is reading this, please steal this feature for CloudFormation!

The solution is not to specify desired capacity in CFN at all. It used to be a mandatory parameter, but hasn't been for a while now

This is a very nice feature, and I'm going to take a close look at Terraform. If you are already using cloudformation, I'd recommend applying stack policies that deny permission to "Update:Replace" or "Update:Delete" any resources. When you need to, you can use a one-time policy that lets you blow away specific resources, by name or type.

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid...

Or to anything that is "kind of a biggie" (not just deletes) in VPC networking: - AttachInternetGateway / DeleteInternetGateway / DeleteCustomerGateway - AssociateRouteTable / DeleteRoute / DeleteRouteTable / CreateRoute / DisassociateRouteTable - ReplaceNetworkAclAssociation - And all the "Delete"s

Got it. So Terraform is not a first on "updates existing resources" but on having "execution plan" to know what it would do before doing it.

(I also was confused by the original wording. Thanks for clarifying.)

I'm surprised that the CloudFormation team hasn't added a --dry-run option yet. It would make CF sooooo much more usable for a production stack. (I have a policy now to never update a stack once it's taking production traffic.)

This would help, but its not enough. `--dry-run` tells you what it would do at a point-in-time, but isn't a guarantee that by the time you update a stack that that is what would actually happen.

Terraform's execution plans, on the other hand, can be saved and applied. This tells Terraform that it can _only_ apply what is in the plan. It _must not_ do anything else.

To match TF here, CloudFormation would really need "staged changes and applied changes" as separate steps.

You're right, TF's strategy sounds great. However, `--dry-run` would still get me 95% the way to where I'd need to be to use CF in production.

I'm reading through the TF docs now... It looks like it doesn't support enough AWS resources for me to replace CF with it yet, but I'd sure love to.

That's sounds like a great feature; you are correct, one of the biggest pain points with Cloud Formation is the need to devine which actions will be taken in response to changes.

Yes it is and CF keeps on saying they'll do it next Q, for nearly a year now. Going to be glad to get off CF. ;-)

Reply on news.ycombinator.com