For a second I confused this with TerraGen (https://planetside.co.uk/) and got all excited about reliving a nostalgic youth.
Terraform 0.12
91–100 of 167 posts
Re: Terraform 0.12
#92The upgrade path for this has been an absolute nightmare, made worse by the fact that we sat on the `google` provider 1.16 (lots of GKE stuff like node taints was moved out to `google-beta` in `google` 2.0 and TF 0.12 requires `google` 2.5 at least). There isn't even a straightforward transformation for many things. I get why it's this way, but brace yourself.
I also made the mistake of `terraform plan`ning and updating my code as I went along. Just use `terraform validate`. Otherwise you're going to inadvertently promote the statefile before you're done dealing with all the issues (and you don't want that because it prevents you from aborting your upgrade and switching back to 0.11 till you're all ready). Not a real problem because the statefile is versioned but an annoyance nonetheless.
The type issues were mostly easy to deal with, except for where things that were assignments now being blocks. For instance, look at this:
master_authorized_networks_config {
cidr_blocks {
cidr_block = "10.0.0.0/8"
display_name = "Example /8"
}
cidr_blocks {
cidr_block = "10.1.2.3/32"
display_name = "Example /32"
}
}
master_authorized_networks_config = {
cidr_blocks = [
{
cidr_block = "10.0.0.0/8"
display_name = "Example /8"
},
{
cidr_block = "10.1.2.3/32"
display_name = "Example /32"
},
]
}
Still, I'm thrilled for the new stuff with the more type-safety. Not going to complain. If this is the price, then I'll pay. I just wish they'd done more to help the upgrade, but it's an 0.x release so fine.
Re: Terraform 0.12
#93Earlier quoted context omitted.
Someday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.
Wonder why you got downvoted, as someone who has been using ansible for years to accomplish what was said and what you accomplish with puppet I wonder what I am missing out of terraform
There's a lot of overlap but, in general, Terraform is focused on orchestrating things while Puppet is more about configuration management.
Plus, the different philosophies of mutable/immutable infrastructure that the different capabilities/limitations in each tool encourage.
Re: Terraform 0.12
#94Earlier quoted context omitted.
Viewing Terraform solely through the lens of cloud automation and in comparison with CloudFormation is a shortsighted mistake. Terraform has providers for plenty of other services that don't qualify as "cloud things" and lack proper configuration of their own. In a very general sense, Terraform is a terrific resource management tool with state versioning & locking built in. For example, there's a terraform-kafka-prov…
Someday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.
Doesn't puppet only support success/changed/error status for resources? How does it work with AWS infrastructure where you may need to possibly remove dependencies before the change, update the resource in place, or update other resources to point at what you just created? You need at least 5 states, I believe? (That depend on properties, not resources, so notification is not enough)
Re: Terraform 0.12
#95I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After using it for a very short period of time I was shocked developers continued to struggle through CF templates and the fragility the whole process entailed.
this is short-sighted. Terraform and CloudFormation are not even in the same league. One of them works and actually can be used for Infrastructure as Code, the other one does not roll back in the face of failure - it effectively craps for reasons ranging from network failure, process crash, even normal operation. One is heavy kool-aid with bugs that go unresolved for years, the other behaves as advertised. Sorry, but…
Well, if you don't follow the obvious advice of storing your state in a S3 bucket... If the idea of storing your state somewhere is so abhorrent for you, you can also tag your resources and import them with Ansible/Bash as per the obligatory CloudFormation workflow. Then your state becomes local-only. That's a pretty useless thing to do for purely ideological reasons, though: storing your state in a cloud-agnostic way is what allows being able to manage a Gitlab repo, a Cloudflare domain and AWS or GCP instances in the same tool. That is what the "multi-cloud" means.
If you are saying a nonsensical argument like "not IaC because it can't rollback" I can say CloudFormation is not IaC because it can't even import a local file to grab some values. Or run external commands
Re: Terraform 0.12
#96If you love terraform, please also look at Pulumi (I have no affiliation with them). https://pulumi.io/reference/vs/terraform.html https://github.com/pulumi/tf2pulumi
Honestly I like the idea of using declarative code for infra stuff because this way it becomes an inventory-like configuration language. There is a reason why YAML dominates today.
Re: Terraform 0.12
#97Earlier quoted context omitted.
Someday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.
You are implying that people who use Terraform are not aware of Puppet. Puppet is a terribly complicated thing compare to Terraform. We use both on a daily basis and everybody agrees that we need to move away from Puppet. Terraform + Ansible is the way for us to go.
It is nice that puppet defines a graph of dependencies compared to doing this in ansible.
What I find tough is that you have another indirection when using puppet to configure your tools. So you first have to figure out the puppet module’s configuration and how it maps onto the actual tools configuration
Re: Terraform 0.12
#98As someone using Terraform from it's first release on I still think that Terraform has one fundamental flaw:
It always looks at things using provider specific resource, while IMHO it should just expose a bunch of predefined resource types (see rOCCI specs e.g.) and then allow you to attach a specific provider to it.
IMHO the biggest win as a user would be having not to have an implementation for every provider over and over. Do we really need to have a consul module for Azure, AWS, Tudeluuu and god knows who? No.
That being said, Terraform in the long run still is the most reliable tool in that space.
The whole situation about state management is... lacking. Experience says the one thing no client ever wants in the cloud but always on prem is state.
Re: Terraform 0.12
#99As someone using Terraform from it's first release on I still think that Terraform has one fundamental flaw: It always looks at things using provider specific resource, while IMHO it should just expose a bunch of predefined resource types (see rOCCI specs e.g.) and then allow you to attach a specific provider to it. IMHO the biggest win as a user would be having not to have an implementation for every provider over a…
> The whole situation about state management is... lacking. Experience says the one thing no client ever wants in the cloud but always on prem is state.
Hm, can you elaborate? S3 state seems perfectly serviceable, and I don't immediately see why I would want to operate on-prem resources just to maintain state.
Re: Terraform 0.12
#100Earlier quoted context omitted.
this is short-sighted. Terraform and CloudFormation are not even in the same league. One of them works and actually can be used for Infrastructure as Code, the other one does not roll back in the face of failure - it effectively craps for reasons ranging from network failure, process crash, even normal operation. One is heavy kool-aid with bugs that go unresolved for years, the other behaves as advertised. Sorry, but…
I mean, this is harsh, but there's a running joke that the big feature terraform is missing is a -twice flag so that it'll re-run itself on failure, since that's what you end up having to do anyways. Also, the terraform language, HCL? It's, I guess there's no better way to put this: not good. Am I misunderstanding the complexity of what Terraform is trying to do? To me, it looks like a bunch of tiny API clients tied…
It basically depends on the formation of your team.
A bunch of oldschools sysadmins who "don't code"? Terraform is ridgid and on-rails enough that it probably helps sort of keep things sensible compared to just using boto. Almost like it was a framework, specifically defined to do that sort of thing.
It does sort of suck though, but what sucks less?
Edit: My solution is to stick as much as possible into k8s, but obviously that comes with its own warts, and to be fair to terraform, a lot of terraforms warts are just the underlying API warts leaking through.