Terraform 1.0
github.com
Terraform 1.0
1–10 of 315 posts
Re: Terraform 1.0
#2An interesting document is also what is actually covered by the 1.0.0 compatibility guarantee: https://www.terraform.io/docs/language/v1-compatibility-prom...
Re: Terraform 1.0
#3It’s a symbolic step but hopefully goes a long way to convince various decision makers about long term viability of hashicorp products.
I remember when a colleague didn’t want to use TF from an unknown company in his saas. His company is now gone but terraform is alive and widely used.
Re: Terraform 1.0
#4It’s a symbolic step but hopefully goes a long way to convince various decision makers about long term viability of hashicorp products. I remember when a colleague didn’t want to use TF from an unknown company in his saas. His company is now gone but terraform is alive and widely used.
I think it's a very meaningful step, as it signals maturity - the platform changed significantly over the last couple of years, and it's (unfortunately but necessary) a pain to perform some upgrades, or at least, to redesign according to the new features.
For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had we started using TF now, we wouldn't have had this problem. But of course, nobody's at fault here.
Re: Terraform 1.0
#5Congrats to Hashicorp for this milestone!
We've been using terraform for a couple of years now to manage our infra for dev/qa/prod, and aside from minor HCL changes we haven't had any major problems keeping up with the latest versions. Having the ability to rebuild everything (Kubernetes, DNS, MySQL, etc.) automatically has saved us more than once!
Re: Terraform 1.0
#6Just be careful with your state file when upgrading!
Re: Terraform 1.0
#7It’s a symbolic step but hopefully goes a long way to convince various decision makers about long term viability of hashicorp products. I remember when a colleague didn’t want to use TF from an unknown company in his saas. His company is now gone but terraform is alive and widely used.
I think it's a very meaningful step, as it signals maturity - the platform changed significantly over the last couple of years, and it's (unfortunately but necessary) a pain to perform some upgrades, or at least, to redesign according to the new features. For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had…
module.count was added in TF 0.13 [1] but yet still what you say makes totally sense, and I really welcome a 1.0 release hoping that there won't be any more disruptive changes and revolutions in the DSL, because yeah, you definitely need to invest a lot of time in refactors/rewrites to keep it up with newer Terraform versions and language features.
[1] https://github.com/hashicorp/terraform/blob/v0.13/CHANGELOG....
Re: Terraform 1.0
#8It’s a symbolic step but hopefully goes a long way to convince various decision makers about long term viability of hashicorp products. I remember when a colleague didn’t want to use TF from an unknown company in his saas. His company is now gone but terraform is alive and widely used.
I think it's a very meaningful step, as it signals maturity - the platform changed significantly over the last couple of years, and it's (unfortunately but necessary) a pain to perform some upgrades, or at least, to redesign according to the new features. For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had…
I think the biggest problem is that the state file is a JSON blob who's hierarchy directly maps the structure of your code in Terraform. This makes refactoring a nightmare as you're continually having to fudge the state file and/or declare that a resource defined in code relates to a resource defined in state (I forget the exact CLI flag you pass to do this off hand).
Re: Terraform 1.0
#9I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it.
The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. The work around is to use two separate Terraform stacks which brings a lot of pain for passing values across the boundary. Furthermore you can no longer effectively plan any change that affects the boundary between the two stacks. "Luckily" Terraform's performance is so bad that you need to split the stacks anyways.
The biggest feature I would like to see is the ability to dump a pure representation of your evaluated configuration. This would allow reasonable diffs in CI. There are of course complications, especially if you use `data` resources but technically it is possible to do a very good job here which would make it so much easier to make changes.
Re: Terraform 1.0
#10I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…
I never used Terraform, I started with Vagrant, then CloudFormation, CDK, and now Pulumi.
I like Pulumi the most right now.
It integrates with services like Cloudflare and Auth0 and I can use TypeScript to write my code.