Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform 0.15 General Availability

hashicorp.com

Post reply on HN
Print view View original

91–100 of 239 posts

Re: Terraform 0.15 General Availability

#91

Post by m1keil »

mr_C wrote: post #56
diroussel wrote: post #51

Earlier quoted context omitted.

If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whe…

Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.

You pay for some of these (like dangling IP addresses not in use) and some others have a max quota (like security groups).

Re: Terraform 0.15 General Availability

#92

Post by encryptluks2 »

manishsharan wrote: post #90
rantwasp wrote: post #88

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…

Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.

When using Terraform you should think of your IaC as the plans to build or rebuild your infrastructure, not an extension. I built mine in a way where I can destroy all the infrastructure in a plan and then reapply. You don't have to worry about rollbacks when you can just rebuild everything without affecting your end service.

Re: Terraform 0.15 General Availability

#93

Post by dekhn »

terraform was a great idea but the language makes devops folks have to do a lot of extra work, purely due to language design features. Terragrunt helps with a lot of that, but combined with the version churn, long-standing bugs, and more, I really wanted an alternative that was small, and simple.

Also: why isn't the state file created at command invocation by querying AWS for the state? Or at least have an option to generate the simplest TF for your current AWS state.

Re: Terraform 0.15 General Availability

#94

Post by ramoz »

rantwasp wrote: post #88

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…

I love your comment,"YOLO-ing" gave me a laugh, and a laugh at myself in some previously stressful/complex deployment periods. Terraform was not a friend there.

That said, I've worked on/with a team enabling some fairly advanced & streamlined capabilities across all three clouds because of Terraform. The abstraction matters, and ability to model scaled platform components and architectures as singular units is important. The open source community is great.

Re: Terraform 0.15 General Availability

#95

Post by oxplot »

rantwasp wrote: post #88

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…

> use whatever the cloud you are using has built it (cloudformation, deployment manager, etc).

Not applicable if you're deploying infra across cloud (we do that across a dozen cloud providers!). Without terraform, it'll bring us tears.

> Or about when it just loses tracks of resources.

Never had this in years of using terraform. These should be qualified with how often they occur.

> Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure.

Checkout the code from before the change and apply again. I've done this numerous times and it's been as good as a natively supported rollback.

> HCL? A disaster.

Why is it a disaster? I find it predictable, ergonomic and easy to write. I also really like the JSON compatibility. But this one is I guess mostly taste.

> it's a terrible tool

I've found Cloudformation to be an abomination as far as user experience goes! Every time I used it, I lost a bit of my soul.

Re: Terraform 0.15 General Availability

#96

Post by mwarkentin »

manishsharan wrote: post #90
rantwasp wrote: post #88

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…

Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.

Cloudformation rollback is not exactly bulletproof either.

Re: Terraform 0.15 General Availability

#97

Post by mwarkentin »

dekhn wrote: post #93

terraform was a great idea but the language makes devops folks have to do a lot of extra work, purely due to language design features. Terragrunt helps with a lot of that, but combined with the version churn, long-standing bugs, and more, I really wanted an alternative that was small, and simple. Also: why isn't the state file created at command invocation by querying AWS for the state? Or at least have an option to…

For the latter: https://github.com/GoogleCloudPlatform/terraformer

Re: Terraform 0.15 General Availability

#98

Post by matwood »

garymoon wrote: post #63
llbeansandrice wrote: post #2

Perhaps off-topic but how have people upgraded TF codebases to new versions? Just last year we had a big effort to upgrade a huge code-base from 0.11 to 0.12. I feel like it should be a lot smoother than a full-team full-sprint effort.

I upgraded from 11 to 12 like one year ago and from 12 to 13 some days ago (upgrade to 14 seems that will be straightforward) but in my case what I did: - Don't upgrade directly from 12 to 14, go to 13 first - If you have warnings after moving from 11, fix them first - Run the 0.13upgrade command in your code that will generate the required_providers - Run terraform-v13 init - Change to correct workspace if using som…

> Don't upgrade directly from 12 to 14, go to 13 first

The line above, plus running apply in each version is key. I literally just did the update from 11->latest for 3 different repos a couple of weeks ago. And tbh, its was only the first update where I had to make any code changes. The rest mostly worked.

Re: Terraform 0.15 General Availability

#99

Post by aprdm »

dasil003 wrote: post #39
dxxvi wrote: post #18

My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform

Have you ever set something up manually via AWS console, then 6 months later totally forgot the steps you took and end up wasting a lot of time reverse engineering what you did in order to make a comparatively small change? After that perhaps you vowed to take better notes, so the next time you do it that way, but then 6 months later you find that you missed some detail, or there was some changes in between that were…

The jump from what you mentioned in paragraph 2 to 3 is not necessarily Terraform. You can use other tools, like Ansible, that IMO have a much better framework than Terraform. I use Terraform for extremely simple stuff that is easy to destroy/recreate. Projects of bigger scale IMO are better served with Ansible and friends.

Re: Terraform 0.15 General Availability

#100

Post by leetrout »

mwarkentin wrote: post #96
manishsharan wrote: post #90

Earlier quoted context omitted.

Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.

Cloudformation rollback is not exactly bulletproof either.

Especially initial deploys that rollback and you have to delete the stack to try to deploy again. Waste of time.

On the whole terraform is much faster too.

Post reply on HN