I do like how most people here sort of forgot that a decent amount of people in ops(especially in bigger enterprise company) are not programmer and at most have shell scripting experience and thats about it, telling them to "use a real programming language" is going to create some "fun" issues (atleast HCL is consistent)
Terraform 1.0
261–270 of 315 posts
Re: Terraform 1.0
#262Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…
Its just an awful language.
Using it is like writing msdos batch files where you are constantly working around limitations and bizarre syntax.
Re: Terraform 1.0
#263I recently had to do a piece of AWS work that required cross-account resources (create certificate in one account with ACM, set DNS entries on Route53 in another account). Not sure about pulumi, but AWS CDK and CloudFormation can't handle that as one step (there are some horrific hacks). With Terraform it's absolutely trivial. I was liking CDK up to that point, but that limitation is a complete deal breaker for me. H…
FYI this has been supported in CDK for a few months now. See the CrossAccountZoneDelegation at the end of this section: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-route53-...
Re: Terraform 1.0
#264Please give me a vim plugin that allows me to easily move through terraform files as opposed to being forced to grep for relationships.
As it stands I hate dealing with terraform because it is horrifyingly undiscoverable.
Re: Terraform 1.0
#265I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…
You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!
If I was doing things from the ground up, I'd pulumi it, I believe.
Terraform is, however, optimized for everyone under the bell curve.
Re: Terraform 1.0
#266Please give me a vim plugin that allows me to easily move through terraform files as opposed to being forced to grep for relationships. As it stands I hate dealing with terraform because it is horrifyingly undiscoverable.
This has less to do with vim than with Terraforms poor LSP support.
Vim/Neovim has had LSP support for some time with plugins and now built in natively.
I use COC vim as it's the fastest to get started and I rarely have to do much config as it's based on VSCode and comes with sane bindings for go-to-def, refactoring and more. https://github.com/neoclide/coc.nvim https://github.com/prabirshrestha/vim-lsp https://github.com/neovim/nvim-lspconfig
You can try to use either of these implementations: https://github.com/juliosueiras/terraform-lsp https://github.com/hashicorp/terraform-ls
These are both fairly limited but you can see every editor (except intellij) uses this under the hood.
I've used them at companies with 300+ terraform repos and have never had much of an issue navigating/understanding TF through Vim.
Re: Terraform 1.0
#267I recently had to do a piece of AWS work that required cross-account resources (create certificate in one account with ACM, set DNS entries on Route53 in another account). Not sure about pulumi, but AWS CDK and CloudFormation can't handle that as one step (there are some horrific hacks). With Terraform it's absolutely trivial. I was liking CDK up to that point, but that limitation is a complete deal breaker for me. H…
Have you seen Terraform CDK? https://github.com/hashicorp/terraform-cdk
A CDK-style Terraform seems perfect. Seems a bit early days but I look forward to it gaining traction.
Re: Terraform 1.0
#268Earlier quoted context omitted.
I really prefer the Pulumi approach where you define the configuration in your favorite Turing-complete language. Not sure why Hashicorp felt the need to reinvent the wheel instead of having a library in an existing language generate markup or JSON or something like that.
The biggest issue with Pulumi is that Pulumi doesn't support adding custom API providers. Part of the power of Terraform is in provisioning infrastructure, orchestration, deployment, and application configuration all in one tool. For example: (aforementioned GitHub provider) https://registry.terraform.io/providers/terraform-provider-c... for Concourse (CI/CD) https://registry.terraform.io/providers/coralogix/coralogi…
> This would be completely impossible with Pulumi. If Pulumi didn't bless it, it doesn't exist in Pulumi's world.
This is only true (temporarily) for automatic plug-in installation - and was until recently also true of Terraform. In fact I had to reverse engineer the TF provider registry protocol because the documentation is manifestly incorrect, recently.
$WORK has lots of Pulumi plug-ins which they know nothing of the existence of, and it works fine.
Re: Terraform 1.0
#269Earlier quoted context omitted.
I really prefer the Pulumi approach where you define the configuration in your favorite Turing-complete language. Not sure why Hashicorp felt the need to reinvent the wheel instead of having a library in an existing language generate markup or JSON or something like that.
Can't agree enough. Declarative programming makes sense for lots of things, React is a great example. With such a big dependency graph for infra, adding loops and variables and templating to be able to achieve the same thing as Pulumi in a "declarative" way is ultimately just harder and worse than using a familiar powerful language with an SDK.
Worth noting that Pulumi IS declarative - the languages build a graph imperatively, but the evaluation is declarative in nature.
Re: Terraform 1.0
#270Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…
I haven't done a lot of infrastructure work in the past few years so haven't stayed super on top of the latest changes. I last used it heavily in the earlier days, roughly 4-7 years ago now. And while a lot of the community was great, put in a lot of work on the product, and generally wanted to improve the tool, there were also a lot of very vocal stodgy old timers that were really resistant to any improvements from…
> very vocal stodgy old timers that were really resistant to any improvements from the very earliest days
As one of the three maintainers of Terraform (for the core and all providers) in that time frame, your characterisation is not particularly accurate - likely hence the downvotes.
Many of the “suggestions” in that time frame were “we should do something and ‘X’ is something so we should do ‘X’” - which is to a large extent how TF came into being.
From the earliest days, breaking changes were avoided - policy which was not retained through later versions.
While you may have heard some “core developers” claim that reuse was unnecessary (I can’t claim omnipresence), the HashiCorp official training that I taught during that time period _used modules extensively_ for this.