tf init fails due to requirement for provider hashicorp/sumologic
jd-sumo opened this issue · 4 comments
hey folks - I’m hitting errors with the non-existent provider hashicorp/sumologic.
I have an empty terraform project I’m initializing using our tf provider (specifying source = "Sumologic/sumologic" ).
The empty project initializes correctly (below shows initializing with a clean plugin-cache):
➜ tf-sumo terradebug init
Initializing the backend...
Successfully configured the backend "local"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing modules...
- sumo in modules/sumo
- sumo.cip in modules/sumo/cip
- sumo.csiem in modules/sumo/csiem
- sumo.csoar in modules/sumo/csoar
Initializing provider plugins...
- Reusing previous version of sumologic/sumologic from the dependency lock file
- Installing sumologic/sumologic v2.24.0...
- Installed sumologic/sumologic v2.24.0 (signed by a HashiCorp partner, key ID 58C1F2777F8E2367)
[... cut for brevity]
➜ tf-sumo terradebug providers
Providers required by configuration:
.
├── provider[registry.terraform.io/sumologic/sumologic] ~> 2.24
└── module.sumo
├── module.csoar
├── module.cip
└── module.csiem
➜ tf-sumo
…but as soon as I add in the data source sumologic_caller_identity, I get the following error citing a requirement for a provider at hashicorp/sumologic:
tf-sumo terradebug init
Initializing the backend...
Initializing modules...
Initializing provider plugins...
- Reusing previous version of sumologic/sumologic from the dependency lock file
- Finding latest version of hashicorp/sumologic...
- Using previously-installed sumologic/sumologic v2.24.0
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/sumologic: provider registry
│ registry.terraform.io does not have a provider named registry.terraform.io/hashicorp/sumologic
tf-sumo terradebug providers
Providers required by configuration:
.
├── provider[registry.terraform.io/sumologic/sumologic] ~> 2.24
└── module.sumo
├── provider[registry.terraform.io/hashicorp/sumologic]
├── module.csoar
├── module.cip
└── module.csiem
➜ tf-sumo
For reference, the only change was adding this single entry in the module.sumo's data.tf :
#********************
#* data.tf
#* (sumo module)
# Includes:
# Sumo Logic data resources
#********************
data "sumologic_caller_identity" "current" {}
I’ve got the trace-level terraform logs for both the working case and the busted case.
In the busted case's init trace log, I see a mysterious GET request out to https://registry.terraform.io/v1/providers/hashicorp/sumologic/versions which does not appear in the trace log for the working case:
[cut for brevity]
2023-07-13T12:04:35.784-0400 [TRACE] statemgr.Filesystem: reading initial snapshot from terraform.tfstate
2023-07-13T12:04:35.784-0400 [TRACE] statemgr.Filesystem: snapshot file has nil snapshot, but that's okay
2023-07-13T12:04:35.784-0400 [TRACE] statemgr.Filesystem: read nil snapshot
2023-07-13T12:04:35.784-0400 [TRACE] ModuleInstaller: installing child modules for . into .terraform/modules
2023-07-13T12:04:35.785-0400 [DEBUG] Module installer: begin sumo
2023-07-13T12:04:35.787-0400 [TRACE] ModuleInstaller: Module installer: sumo <nil> already installed in modules/sumo
2023-07-13T12:04:35.787-0400 [DEBUG] Module installer: begin sumo.cip
2023-07-13T12:04:35.789-0400 [TRACE] ModuleInstaller: Module installer: sumo.cip <nil> already installed in modules/sumo/cip
2023-07-13T12:04:35.789-0400 [DEBUG] Module installer: begin sumo.csiem
2023-07-13T12:04:35.790-0400 [TRACE] ModuleInstaller: Module installer: sumo.csiem <nil> already installed in modules/sumo/csiem
2023-07-13T12:04:35.790-0400 [DEBUG] Module installer: begin sumo.csoar
2023-07-13T12:04:35.790-0400 [TRACE] ModuleInstaller: Module installer: sumo.csoar <nil> already installed in modules/sumo/csoar
2023-07-13T12:04:35.790-0400 [TRACE] modsdir: writing modules manifest to .terraform/modules/modules.json
2023-07-13T12:04:35.792-0400 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2023-07-13T12:04:35.793-0400 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
2023-07-13T12:04:35.958-0400 [DEBUG] GET https://registry.terraform.io/v1/providers/sumologic/sumologic/versions
2023-07-13T12:04:35.958-0400 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/sumologic/sumologic/versions
2023-07-13T12:04:36.009-0400 [DEBUG] GET https://registry.terraform.io/v1/providers/hashicorp/sumologic/versions
2023-07-13T12:04:36.009-0400 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/hashicorp/sumologic/versions
2023-07-13T12:04:36.065-0400 [TRACE] providercache.fillMetaCache: scanning directory .terraform/providers
2023-07-13T12:04:36.065-0400 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/sumologic/sumologic v2.24.0 for darwin_amd64 at .terraform/providers/registry.terraform.io/sumologic/sumologic/2.24.0/darwin_amd64
2023-07-13T12:04:36.065-0400 [TRACE] providercache.fillMetaCache: including .terraform/providers/registry.terraform.io/sumologic/sumologic/2.24.0/darwin_amd64 as a candidate package for registry.terraform.io/sumologic/sumologic 2.24.0
let me know if you need any other details to repro
Most likely there is some misconfiguration. It looks like you have some wrapper over terraform? Can you add more details?
terradebug is just a shell alias I use when troubleshooting:
alias terradebug="TF_LOG_PATH=terraform-\$(date +%Y%m%d_%H%S).log TF_LOG=TRACE terraform"
I found the misconfig - omitting the required_providers block in the child modules, assuming implicit provider configuration inheritance would obviate the need for explicit declarations (wrong!).
This omission caused terraform's pre .13 compat behavior to sneak in, described here:
Note: If you omit the source argument when requiring a provider, Terraform uses an implied source address of registry.terraform.io/hashicorp/<LOCAL NAME>. This is a backward compatibility feature to support the transition to Terraform 0.13; in modules that require 0.13 or later, we recommend using explicit source addresses for all providers.