3 ms·

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 w

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 http://www.terraform.io/intro/vs/cloudformation.html [1]: http://www.terraform.io/docs/commands/plan.html http://www.terraform.io/docs/commands/plan.html

onedognight 12y ago
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.
letmeinhere 12y ago
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/UserGuide/protect-stack-resources.html http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid...
- hyperliner 12y ago
  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
sciurus 12y ago
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!
- bashtoni 12y ago
  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
hyperliner 12y ago
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.)
zwily 12y ago
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.)
- mitchellh 12y ago
  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.
  - zwily 12y ago
    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.
doxcf434 12y ago
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. ;-)

onedognight 12y ago

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.

letmeinhere 12y ago

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/UserGuide/protect-stack-resources.html http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid...

hyperliner 12y ago
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

sciurus 12y ago

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!

bashtoni 12y ago
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

hyperliner 12y ago

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.)

zwily 12y ago

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.)

mitchellh 12y ago
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.
- zwily 12y ago
  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.

doxcf434 12y ago

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. ;-)