Live data from Hacker News

Terraform is currently not reviewing community pull requests

github.com

51–60 of 120 posts

Re: Terraform is currently not reviewing community pull requests

#51

Earlier quoted context omitted.

No, reading code is far easier than writing it. Either way both have go be done regardless of the author.

> No, reading code is far easier than writing it. I'm gonna say I think that's flat out wrong in most cases. Obviously there's a grey area for trivial stuff.

For a one word docs grammar patch, it could be true (and not always, there).

For anything more than a one character code patch, there's so much more complexity that goes into a good review than most people appreciate.

Not to mention the weighing of potential maintenance costs, changelog messaging, etc., even if it may just be a tiny tweak or small parameter change.

Re: Terraform is currently not reviewing community pull requests

#52
post #27

One of these days Hashicorp is going to cash in and one of the major cloud operators will own the lingua franca of cloud provisioning. Oracle, for instance, directs the cloud users to Terraform as its de facto first class provisioning tool. It works rather well BTW.

I've been very happy with Terraform. I also have a huge investment in Cloudformation and it doesn't take long to discover that Cloudformation isn't implemented consistently across services, it's full of bugs, and unless your bug happens to impact Amazon internally you can wait years for a fix. New functionality for existing resources can also take years to materialize. Back when I had an eight figure AWS budget they…

Looking at what CloudFormation can and can't do it seems like completely different teams work on a service and its CloudFormation support. I guess Amazon use the AWS API internally?

Re: Terraform is currently not reviewing community pull requests

#53

Earlier quoted context omitted.

I've been very happy with Terraform. I also have a huge investment in Cloudformation and it doesn't take long to discover that Cloudformation isn't implemented consistently across services, it's full of bugs, and unless your bug happens to impact Amazon internally you can wait years for a fix. New functionality for existing resources can also take years to materialize. Back when I had an eight figure AWS budget they…

Looking at what CloudFormation can and can't do it seems like completely different teams work on a service and its CloudFormation support. I guess Amazon use the AWS API internally?

I work at AWS. The service teams do own and write their CloudFormation providers, although if you've written a custom provider you'd see it is somewhat clunky, so it's sometimes considered more of an operational burden, and you can tell.

We dogfood both the SDK and CloudFormation internally, we just deal with its numerous gripes much the same way you would externally (although we can also contact service teams directly if needed).

Re: Terraform is currently not reviewing community pull requests

#54

Props to them for being honest, but it's still not a good look for Hashicorp. Their stewardship of Terraform leaves a lot to be desired. For years now I've watched Terraform PRs just wither on the vine. You get the impression that nobody is working on the AWS provider at all. Every PR to the AWS provider that I've ever cared about has taken years to be reviewed and merged despite lots of thumbs-ups and comments from…

There's a group called cloudposse who have a huge repository of their own terraform AWS plugins. I haven't had to use their plugins yet (I've been lucky so far in having found a way to do most of what I've wanted through the official provider) but their selection is pretty comprehensive:

https://registry.terraform.io/search/modules?namespace=cloud...

https://github.com/orgs/cloudposse/repositories?q=aws+terraf...

Re: Terraform is currently not reviewing community pull requests

#55

Earlier quoted context omitted.

I've been very happy with Terraform. I also have a huge investment in Cloudformation and it doesn't take long to discover that Cloudformation isn't implemented consistently across services, it's full of bugs, and unless your bug happens to impact Amazon internally you can wait years for a fix. New functionality for existing resources can also take years to materialize. Back when I had an eight figure AWS budget they…

Looking at what CloudFormation can and can't do it seems like completely different teams work on a service and its CloudFormation support. I guess Amazon use the AWS API internally?

They've been publishing a lot of the alleged source code to their CFN providers of late, so one can see how the sausage is made: https://github.com/aws-cloudformation?q=aws-cloudformation-r...

I say alleged because who knows if that's the code that's really running. And related to this current thread even if it is the code, with this being Amazon who knows if I ever found a bug and PR-ed it that it wouldn't /dev/null for 5 years before being closed by some stale-issue-bot or something

Re: Terraform is currently not reviewing community pull requests

#56

Earlier quoted context omitted.

I do this. I wish I didn't. First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes…

heh. i've been considering a switch from ansible to terraform because i've been frustrated by ansible's limited support for some of the edge cases around ALBs. good to hear that terraform also sucks. i'm gradually coming to the conclusion that all the tools that are supposed to make provisioning cloud infrastructure easier aren't as good as a bunch of crappy custom scripts using boto or aws-cli.

One big difference here is that while the tools might all depend on the SDK provided by the cloud, the tools themselves can also do a whole lot of good/wrong on their side. Terraform fixes a lot of that by delivering a 'standard' provider interface with normalised data formats, resource structures and encapsulation. That was pretty much a requirement for the tool to work anyway, otherwise it wouldn't have a unified way to check for configuration drift, plan changes, apply changes, do cleanups etc. You also wouldn't be able to pass data around easily (you'd end up shuffling strings around instead).

Some people prefer to do the CDK thing where you use a general programming language to synthesise the IaC stuff and then run it that way, but that doesn't really fix anything because a CDK is just built on top of the same SDK. As an added insult to injury, you now don't have a domain-specific language so save you from yourself (and your team) with all the anti-patterns you now have at your disposal ;-)

Re: Terraform is currently not reviewing community pull requests

#57

Earlier quoted context omitted.

Yes, just use our own forked version.

I do this. I wish I didn't. First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes…

You can just give your self-compiled provider a different name or namespace but alias it in during normal runtime, saves a lot of grief.

Re: Terraform is currently not reviewing community pull requests

#58
I recall once upon a time there was a GitHub project wherein the owner would just immediately merge any PRs that were opened -- I believe it was a social experiment, and I don't recall the exact nature of the repo in order to know if that kind of thing is ludicrous here. But I do think it'd be good fun to take this lull and find out the outcome of a hypothetical github.com/open-terraform/open-terraform which just ran a github action that merged PRs that had more than a 5(10?) differential of :+1: to :-1: reactions on it. Build failures would instantly close the PR, and test failures would be exempt from auto-merge

If that worked sufficiently well, I'd initially mirror every repo from https://github.com/terraform-providers into that same GitHub organization and continue that exercise. IMHO the providers suffer from bitrot a lot more than formal terraform does

I think of that hypothesis as a "open source optimist" versus "open source pessimist:" are people who go out of their way to open PRs trying to improve the common good, or trying to drain the life out of maintainers?

Re: Terraform is currently not reviewing community pull requests

#59

Surely community patches are such a good return on investment they should be pulling devs off other areas to keep someone on reviewing public prs. I've always been confused by companies that aren't over the moon to spend minimal review time to get the benefit of hours of work by free employees.

My experience has been that the first-order ROI of community PRs is negative. PRs which do more than just fix a typo that you can just go "thanks" and merge are extremely rare. Most external PRs take more work to get into a good state than it would have been for us to fix the problem ourselves.

The main reason to accept community PRs is because it helps you get passionate users, not because they're free labor.

Re: Terraform is currently not reviewing community pull requests

#60

Props to them for being honest, but it's still not a good look for Hashicorp. Their stewardship of Terraform leaves a lot to be desired. For years now I've watched Terraform PRs just wither on the vine. You get the impression that nobody is working on the AWS provider at all. Every PR to the AWS provider that I've ever cared about has taken years to be reviewed and merged despite lots of thumbs-ups and comments from…

Oh, it's absolutely not a good look for Hashicorp because their company culture is the problem. They grew too fast and hired too many middle managers who brought in a brogrammer culture. It drove everyone with better options away (at least per friends who formerly worked on Terraform at Hashi). And from the resumes I see come across my desk it feels like they've been bleeding talent at all levels for a while.
Post reply on HN