I know this has been raised before, but for sometime now sequential versions of the AWS provider take a long time to register during Terraform Init.
This has previously been dismissed as 'network issues' or 'a lot to download' and closed off as such. I've experienced that and fair enough in that scenario.
However, to mitigate the time and size of download I've started using a local version of the provider, fully unpacked so that the end result of the 'install' is only a symlink in the .terraform folder to the locally installed location. It still takes just as long during the init step. No files have moved, nothing has been downloaded.... Is it possible some network lookup is occurring and waiting for a timeout? Is there some other processing or registering taking place? It just seems like the really long delay (that is frequently labelled as network/download time) occurs when nothing is happening.
Obviously there's no errors here, it continues eventually, it's just that the previous reasoning behind the long pause doesn't stack up in this example, so I wonder if someone could consider looking slightly closer at it.
It doesn't look like I'm going to be able to sustain the locally plugin approach anyway because the difference in hashes mean the same version of the provider in a terraform.lock.hcl gets treated differently when it comes from the local cache than if downloaded, so it keeps rendering my saved tf plans stale.
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
Volunteering to Work on This Issue
If you are interested in working on this issue, please leave a comment.
If this would be your first contribution, please review the contribution guide.
Description
I know this has been raised before, but for sometime now sequential versions of the AWS provider take a long time to register during Terraform Init.
This has previously been dismissed as 'network issues' or 'a lot to download' and closed off as such. I've experienced that and fair enough in that scenario.
However, to mitigate the time and size of download I've started using a local version of the provider, fully unpacked so that the end result of the 'install' is only a symlink in the .terraform folder to the locally installed location. It still takes just as long during the init step. No files have moved, nothing has been downloaded.... Is it possible some network lookup is occurring and waiting for a timeout? Is there some other processing or registering taking place? It just seems like the really long delay (that is frequently labelled as network/download time) occurs when nothing is happening.
Obviously there's no errors here, it continues eventually, it's just that the previous reasoning behind the long pause doesn't stack up in this example, so I wonder if someone could consider looking slightly closer at it.
It doesn't look like I'm going to be able to sustain the locally plugin approach anyway because the difference in hashes mean the same version of the provider in a terraform.lock.hcl gets treated differently when it comes from the local cache than if downloaded, so it keeps rendering my saved tf plans stale.
References
No response
Would you like to implement a fix?
None