5 ms·

For any terraform users that may be using code like this: data "cloudflare_ip_ranges" "cloudflare_ipv4_list" {} This is coming back with an empty list on some

For any terraform users that may be using code like this: data "cloudflare_ip_ranges" "cloudflare_ipv4_list" {} This is coming back with an empty list on some fields and causing havoc in terraform.

freedomben 3y ago
It is shocking to me how bad to non-existent error handling is in most terraform providers. It leads to some remarkably arcane and esoteric error messages
- JohnMakin 3y ago
  There was no error message, that was the really unsettling part.
- mschuster91 3y ago
  Terraform error handling as a whole is nuts anyway. Like, I recently tried to delete an ACM cert that still was in use in a Cloudfront distribution - didn't work, but it took 20 minutes for Terraform to recognize that, yes, there's an API error. It shouldn't have come so far given that the API call immediately errors out when trying over the CLI or Web Console, but instead of erroring out, Terraform retried for 20 minutes until it hit some sort of timeout. To make it worse, you can't even kill Terraform safely because while it does register your Ctrl+C, it won't interrupt an ongoing process, and if you force kill it you run the very serious risk of corrupting your state file. Seriously, I'm looking for OpenTofu to light some fire under the ass of Hashicorp. I don't know where all the VC money went, but for what's supposed to be the golden standard of IaC solutions, it's sometimes bloody ridiculous. (Not to mention it's written in Go of all things which means there's virtually zero tooling and documentation to debug it or to develop anything for... especially when compared to the state of the art in Java, NodeJS or PHP)
  - nijave 3y ago
    This is usually down to provider implementation which switching the core won't help. The provider controls HTTP calls and errors against the relevant service API. Here are the retries in the provider code https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/acm/certificate.go#L535C88-L535C88 https://github.com/hashicorp/terraform-provider-aws/blob/mai... It's hard coded to "certificateCrossServicePropagationTimeout" which is 20 minutes here https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/acm/certificate.go#L43C2-L43C43 https://github.com/hashicorp/terraform-provider-aws/blob/mai...
    - mschuster91 3y ago
      Sure, but Terraform Core doesn't provide any way of getting user feedback in case unexpected situations happen, or aborting while saving the current state, both of which would save me serious amounts of time.
      - nijave 3y ago
        Being able to actually interrupt/cancel would be nice. You can get more feedback by adjusting TF_LOG env var. Logging levels have been getting improvements for a while (it used to just be TRACE that spammed everything)
        mschuster91 3y ago
        > You can get more feedback by adjusting TF_LOG env var. yep, but that's often enough useless after the fact. In the PHP world, for example, there's Symfony/Monolog's `fingers_crossed` logger [1]... it keeps logs below the normal threshold in memory, but if there is a single event of a given severity or worse, it dumps out all the logs it has ingested so far for this request. A real lifesaver that one is. [1] https://symfony.com/doc/current/logging.html https://symfony.com/doc/current/logging.html
        nijave 3y ago
        I used to add TF_LOG_PATH to my shell profile so all TF runs log to disk with a daily cron to truncate the file.
- eddyfromtheblok 3y ago
  it's shocking how much of a desirable skill it is in devops job roles given its clear deficiencies.
JohnMakin 3y ago
In the time I made this post and now it's come back. Really wish that would've returned an error and not an empty list, that almost caused a disaster in my automation.

For any terraform users that may be using code like this: data "cloudflare_ip_ranges" "cloudflare_ipv4_list" {} This is coming back with an empty list on some fields and causing havoc in terraform.

freedomben 3y ago

It is shocking to me how bad to non-existent error handling is in most terraform providers. It leads to some remarkably arcane and esoteric error messages

JohnMakin 3y ago
There was no error message, that was the really unsettling part.
mschuster91 3y ago
Terraform error handling as a whole is nuts anyway. Like, I recently tried to delete an ACM cert that still was in use in a Cloudfront distribution - didn't work, but it took 20 minutes for Terraform to recognize that, yes, there's an API error. It shouldn't have come so far given that the API call immediately errors out when trying over the CLI or Web Console, but instead of erroring out, Terraform retried for 20 minutes until it hit some sort of timeout. To make it worse, you can't even kill Terraform safely because while it does register your Ctrl+C, it won't interrupt an ongoing process, and if you force kill it you run the very serious risk of corrupting your state file. Seriously, I'm looking for OpenTofu to light some fire under the ass of Hashicorp. I don't know where all the VC money went, but for what's supposed to be the golden standard of IaC solutions, it's sometimes bloody ridiculous. (Not to mention it's written in Go of all things which means there's virtually zero tooling and documentation to debug it or to develop anything for... especially when compared to the state of the art in Java, NodeJS or PHP)
- nijave 3y ago
  This is usually down to provider implementation which switching the core won't help. The provider controls HTTP calls and errors against the relevant service API. Here are the retries in the provider code https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/acm/certificate.go#L535C88-L535C88 https://github.com/hashicorp/terraform-provider-aws/blob/mai... It's hard coded to "certificateCrossServicePropagationTimeout" which is 20 minutes here https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/acm/certificate.go#L43C2-L43C43 https://github.com/hashicorp/terraform-provider-aws/blob/mai...
  - mschuster91 3y ago
    Sure, but Terraform Core doesn't provide any way of getting user feedback in case unexpected situations happen, or aborting while saving the current state, both of which would save me serious amounts of time.
    - nijave 3y ago
      Being able to actually interrupt/cancel would be nice. You can get more feedback by adjusting TF_LOG env var. Logging levels have been getting improvements for a while (it used to just be TRACE that spammed everything)
      - mschuster91 3y ago
        > You can get more feedback by adjusting TF_LOG env var. yep, but that's often enough useless after the fact. In the PHP world, for example, there's Symfony/Monolog's `fingers_crossed` logger [1]... it keeps logs below the normal threshold in memory, but if there is a single event of a given severity or worse, it dumps out all the logs it has ingested so far for this request. A real lifesaver that one is. [1] https://symfony.com/doc/current/logging.html https://symfony.com/doc/current/logging.html
        nijave 3y ago
        I used to add TF_LOG_PATH to my shell profile so all TF runs log to disk with a daily cron to truncate the file.
eddyfromtheblok 3y ago
it's shocking how much of a desirable skill it is in devops job roles given its clear deficiencies.

JohnMakin 3y ago

In the time I made this post and now it's come back. Really wish that would've returned an error and not an empty list, that almost caused a disaster in my automation.