Comment by pizza234 | Hacker News Reader

Comment by pizza234 | Hacker News Reader

Parent Full thread

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 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.

> 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.

Reply on news.ycombinator.com