Hacker News Reader

Comment by dblooman | Hacker News Reader

One thing I would like to hashicorp do is take pull requests more seriously address them within a certain time period and help new Go engineers with tips on how to finish their PR's for terraform providers. The AWS provider is an example of lack of engagement, leading to stale PRs. At the same time, hashicorp love to shout about day 0 support for a big cloud feature.

View on HN

I have experience with contributing to both Terraform core, and a provider.

The core community maintenance is one of the most responsive and efficient that I've every worked with. Therefore, if they love to shout about day 0 support, I think they have the rights.

The provider project I've contributed to, or better, tried to, has been a complete trainwreck. Many devs discussing on an issue, maintainers ignoring the issue for a long time, then maintainer stepped in with a fundamentally incompetent comment, then disappearing again. This is odd, because the provider is maintained by Hashicorp employees.

There are polite and communicative ways of explaining why it's not possible to work on a fix/feature; that maintenance was far from this.

I suppose that they Hashicorp has a specific plan of maintaining the core very actively, at the cost of doing very poor maintenance on the/some providers. I wouldn't be suprised if they put their less important employees working on the providers.

> I wouldn't be suprised if they put their less important employees working on the providers.

No, that is not the case from what I saw when I worked there. At least one provider was supported by a product team so there was a tension between working on the product or working on the provider and it was easy to lose context on the latest changes another team may have contributed. Contrast that with, say, the dedicated provider developers for AWS where they aren’t pulled in multiple directions.

I concur that provider projects are a mess. When I've reported issues, I've been told "That's not an issue, just do your plan/apply manually in two steps" which is pretty contrary to what you should need to do with Terraform. So many providers github repos have it set to automatically shut down an issue if no one commented on it for 30 days, which means a lot of things that are unaddressed get swept under rugs.

> I've been told "That's not an issue, just do your plan/apply manually in two steps" which is pretty contrary to what you should need to do with Terraform.

Is it? I've been contemplating using Terraform for my org, but I would really like a CI system that generates a plan, lets me review it, and then I can approve it and the plan gets applied. Ideally I think this is how I would like all of my infrastructure to work. (It's how I do changes to Kubernetes stuff; generate some resource manifests then apply the files.)

This is supported by Terraform Enterprise deployment policies.

With the Fastly provider, you cannot create and define lifecycle on an ACL at the same time. Trying it will make the plan blow up. So you have to split it into one commit, plan/apply it, and then do another. If you tear down the entire system with a Terraform destroy, and try it from the ground up - it will fail. This makes testing with something like Terratest nearly impossible, as it will require multiple plan/applies in a row to get the environment up - and it's hard to determine what failures are retryable and aren't.

This sounds far from optimal to me.

Their 30-day auto-close policy is ridiculous. I've run into at least half a dozen bugs in Terraform providers, dutifully gone to report them, and found them auto-closed by the bot. How are they ever going to be addressed with that attitude? At least acknowledge that you don't care and aren't going to fix them.

Yesterday during Hashiconf Q&A for one of the Terraform sessions somebody asked what the plan was for supporting more providers and the answer was basically "We want to get better at supporting the community to maintain as many providers as there are API's"

Which anecdotally anyway, it seems like they're putting some effort into. I started using the community built Auth0 provider in production last year and have seen Hashicorp community engagement people wading into the repo offering pointers and helping get the support / quality level up.

Why should Hashicorp hand-hold "new Go engineers" through PRs? If you don't know how to swim, stay out of the deep end of the pool. If someone contributes a complete, tested, documented, useful PR, that would benefit the community at large, I suspect it would be treated with the respect it deserves. It's not on them to teach people the basics.

If you take the time to write a PR for a project, chances are you have taken the time to read the contributing guide and have tried to submit a passing pull request. There are conventions that may apply to a massive code base, such as those on some of the big providers that not initially clear, so I think spending some time in ensure that you explain why they haven't had a PR merged is worthwhile. Sometimes a PR can be ignored completely.

I guess it depends on whether you want people to try and contribute to your project or whether you insta close the PR because they missed a semi colon, which it seems would be your approach.

Well, I would say in this case because it's fundamentally an "integration ecosystem" platform. The success of terraform is dependent on its deep support of cloud resources, across multiple cloud providers.

Also, this isn't a space they own. It is chock-full of established players (Puppet, Salt, Ansible, Chef).

Hashicorp thus has two choices: rapidly fix/implement requested improvements, or handhold to get as many participants in the ecosystem as possible.

Otherwise, TF will be a spark in the pan, superseded, or restricted to niches. Where I work it already is being relegated only to security groups and network resources, despite armies of stateless HTTP API servers in our microservice smorgasborg.

The real question is, why aren't the multi-hundred-billion-dollar cloud providers ponying up resources for these platforms, which really are the only way to force multiply and scale up on them?

Yeah, AWS would be well-served to own the provider themselves. Sure, they would prefer people use CloudFormation/CDK, but they still get vendor lock-in if they support Terraform. In fact, they'd probably get even more vendor lock-in. As it stands, the Terraform provider is full of annoying bugs. It's still very usable, but if you dive deep, especially with newer AWS services, you're in for some headaches.

Reply on news.ycombinator.com