Hacker News new | ask | show | jobs
by gregmac 472 days ago
Having debugged this sort of thing before, it's actually really hard to figure that out.

The entire stack is kind of bad at both logging and having understandable error messages.

You get things like this:

    ╷
    │ Error: googleapi: Error 400: The request has errors, badRequest
    │ 
    │   with google_cloudfunctions_function.function,
    │   on main.tf line 46, in resource "google_cloudfunctions_function"         "function":
    │   46: resource "google_cloudfunctions_function" "function" ¨
Is this a problem with the actual terraform or passing a variable in or something? Is it a problem with the googleapi provider? Is it a problem with the API? Or did I, as the writer of this, simply forget a field?

In complex setups, this will be deep inside a module inside a module, and as the developer who did not use any google_cloudfunctions_function directly, you're left wondering what the heck is going on.
1 comments
JohnMakin 472 days ago
The nice thing though, if you are a developer, is that most of these providers code is open source. We've had cases where we've forked providers and fixed bugs on our own before we could get something merged in. I've personally fixed several provider bugs on my own out of annoyance - terraform's just a wrapper around cloud API's, usually, and you can be in control of how that works.
link
gregmac 470 days ago
Yep, agreed, and IMHO in a lot of cases, as-is, terraform wouldn't be viable as a closed-source product. At least, I would have got frustrated and ditched it.

I haven't personally found a real bug in terraform or a provider yet, but I've had to refer to the source many times to figure out what is actually happening. It's always been either misuse on my part, or drift that the provider couldn't resolve.

I still consider it a failure though if it takes looking at source code to figure out what's actually going on -- whether it's vendor or in-house. The ironic and annoying part is it usually takes a deeper level of knowledge to write better error messages, but the people with that knowledge don't have the perception of it being a problem. I fight this battle internally with my own teams all the time. The problem is not getting people to make a change, but recognizing that the message is misleading/confusing/unclear to their users (eg: developers who are not domain experts like them) in the first place.

link