3 ms·
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 AP
by 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 agoSure, 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 agoBeing 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 agoI 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.