Error loading modules: host registry.terraform.io #16751
Comments
|
experienced the same issue just now. It was working yesterday. |
|
@thunderbird86 It's working fine for me after I rewrite module to below format. |
|
Hi @thunderbird86, This is covered in the upgrade guide. Relative paths must start with |
|
Hi @thunderbird86, Sorry, the last comment made me think that this was the issue with ambiguous names. That log message only indicates the name conforms to a registry module, not that the source has been located. Is this the extent of your configuration, and is it still repeatable? Using that in a terraform config works fine here. |
|
Hi @jbardin It's have very strange behavior. Right now this module works fine. But i try to init kubernetes module, and have the same issue on Ubuntu 16.04, and at Mac all looks fine |
|
using |
|
@ebarault, that is the case only for relative file paths, which was the case with a earlier comment, but the original issue posted is for a registry module. |
|
@jbardin : ok, so we agree this should work? |
|
@ebarault: yes, that's the correct source for a registry module, which works in most cases. @thunderbird86: Are you possibly running behind a proxy of some sort? Can you provide the full log up to the |
|
For reference, I'm not able to replicate this using various http/https proxy configuration either, though I of course can't account for broken proxies. @thunderbird86: do you possibly have any |
|
It may help to give some additional context about what Terraform is trying to do behind the scenes here, that might be a clue as to how it might be interacting poorly with a local proxy or other such intermediary on your networks. This "does not provide Terraform modules" error is a result of failing to complete the service discovery protocol. You can see the full details of that on that page, but the crux of it is that Terraform wants to fetch If Terraform gets back anything other than a JSON document at this URL, discovery is considered to have failed. Terraform will follow at least one redirect, but still expects the final URL to return a JSON document. One potential cause of this error, for example, would be if you're on a wireless network which uses a "captive portal" to force a login or agree to terms and conditions. This would cause that discovery request to fail (to be blocked outright or to fail its TLS certificate check) and thus cause this error. James mentioned the possibility of # NOTE WELL: The URL declared in here is subject to change at any time, which will
# cause module installation to fail. It is not recommended to leave the following permanently
# in the CLI config, since real network discovery is required to ensure that Terraform will
# automatically adopt any future changes to the module API URL.
host "registry.terraform.io" {
services = {
"modules.v1" = "https://registry.terraform.io/v1/modules/"
}
}It could be informative to try this and see if that makes it work, or if that just leads to a further error accessing the registry API. If the latter, that suggests a general problem with the local network connection, whereas the former could be indicative of a bug in the discovery client. |
|
@jbardin have no proxy. Here full trace log And curl works |
|
@apparentlymart yes it's helps. |
|
Interesting, these are http timeouts causing the failures. While the other instances I've seen of this are TLS handshake timeouts, it might be related to #16448 |
|
Some other interesting things I notice here:
We currently have the discovery timeout set to four seconds and the checkpoint timeout set to three seconds, while the TCP socket timeouts are at their defaults and thus significantly longer. It may just be that four seconds is too aggressive a timeout for users in some locations and we should consider increasing it. |
|
The TLS handshake has a separate timeout at 10 seconds, so not significantly longer. |
|
These are the same error. From the client's perspective, it is waiting for headers even if it's stalled at a lower layer. I verified that you get |
|
I'm having this problem all of a sudden, coincidentally with the terraform-aws-modules/vpc/aws module. The requests for the service discovery and checkpoint URLs always succeed immediately with curl, but terraform has problems with them. I'm not going through any proxies, and there's no captive portals on my WiFi network. I'm at a loss on how to get past this problem. Here's the requests with headers. Click to expand
|
|
I don't think there's actually any network connectivity issues, at least for my case. Perhaps terraform on my Mac is suddenly unable to validate the TLS certificate? Or, there's a library or dependency somewhere that's changed? I created a simple config using the AWS VPC module to test with, and ran Terraform directly on my Mac and in a Docker container on my Mac. I'm on macOS High Sierra, with Terraform v0.11.8 installed via homebrew. Running Click to expand
$ terraform init
Initializing modules...
- module.test
Error downloading modules: Error loading modules: Get https://registry.terraform.io/v1/modules/terraform-aws-modules/vpc/aws/versions: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)If I use the hashicorp/terraform:light image and run Terraform in Docker against the same directory, it works. Click to expand
$ docker container run -it --rm -v $PWD:/tf --workdir /tf hashicorp/terraform:light init
Initializing modules...
- module.test
Found version 1.44.0 of terraform-aws-modules/vpc/aws on registry.terraform.io
Getting source "terraform-aws-modules/vpc/aws"
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "aws" (1.38.0)...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.aws: version = "~> 1.38"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.I've tried several different network locations, and consistently cannot init with my natively installed copy of Terraform anymore, but can with Terraform in the container. This feels more like something that Terraform depends on has changed. Though, I don't know what. |
|
Getting the same issue on 0.12-dev branch but works OK on 0.11.10. |
|
I am also seeing this issue, with terraform 0.11.14, on a Mac. No proxies, captive portals, or anything similar. fetching the url from curl or the browser is instant, but terraform doesn't like it |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Terraform Version
Terraform Configuration Files
Debug Output
Expected Behavior
Actual Behavior
Steps to Reproduce
The text was updated successfully, but these errors were encountered: