Terraform error failed to query available provider packages

Error: Failed to query available provider packages

Problem Description

Performing a terraform run and seeing an error like this:

Prerequisites

• You’re on a Terraform 0.13.0 — 1.0.0 release.
  • NOTE: If you’re on Terraform 1.0.1+ and running into this, please refresh your DNS settings or point to a popular public DNS server like 8.8.8.8
• This issue primarily affects those running Terraform on a MacOS/Linux/Unix platform.

Possible Causes

There are primarily 3 possible reasons for this error:

1). Skipping major terraform versions without following the upgrade guides [a].

2). Not specifying provider sources in your required_providers block [b] AND modules — if you’re on a 0.13+ release (also watching out for typos in your provider declarations).

3). Faulty Golang DNS resolution on UNIX platforms. This one I’ll explain more in detail below — in case that’s what you’re running into (& provided the above two points are satisfied).

This particular issue boils down to Go’s cross-platform DNS client [c] that messes up Terraform’s DNS lookups (Terraform is built using Golang) when looking up provider plugins for you, especially when using a VPN.

Provider creators (e.g Google, Helm & Kubernetes) use different DNS resolution techniques for their provider source domains — which Go’s DNS client does not take into account for MacOS/Linux/Unix platforms, and instead just sticks to /etc/resolv.conf which isn’t always enough.

• NOTE: You don’t see the issue when you run curl against our registry because curl uses your OS’s native resolver chain. If you suspect something is wrong with our Registry website, please check our Status website for confirmation.

This upstream issue affects Terraform 0.13.0 — 1.0.0 releases; and was finally fixed in Terraform 1.0.1 [d][e] when we decided to perform native Terraform builds for each OS platform as opposed to depending on Golang’s cross-platform DNS client.

• It took that long because we (& other members of the OSS community) tried getting Golang’s maintainers to fix the issue [c] in their DNS client, but I’m afraid it’s still open at the time of this article’s writing.

Possible Solutions

With that said, the 3 most-popular workarounds are to:

• build/compile terraform from source [f],
• let your OS’s native DNS server do the resolution for you, i.e removing any custom DNS servers you might have [g], OR
• subscribe to a popular public DNS server e.g 8.8.8.8 [h].

[Optional] You can also see references [i-k] for more threads on how other customers have run into this issue and resolved them.

Hope that helps! For further questions on this, please feel free to chat with the Terraform community on our Discuss forums or open a Support ticket. Thank you.

Источник

[BUG] Error: Failed to query available provider packages #270

Cloned this repo and without changing anything other than providing the Digital Ocean key:

export DIGITALOCEAN_TOKEN=’Token from Digital Ocean’

Steps to produce:
cd terraform-provider-rke/examples/digitalocean
terraform init

Warning: Interpolation-only expressions are deprecated

on rke.tf line 64, in resource «rke_cluster» «cluster»:
64: addons = «$«

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/digitalocean: provider registry registry.terraform.io does not have
a provider named registry.terraform.io/hashicorp/digitalocean

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider hashicorp/rke:
provider registry registry.terraform.io does not have a provider named
registry.terraform.io/hashicorp/rke

(.venv) ➜ digitalocean git:(master) terraform —version
Terraform v0.14.2

Mac Big Sur: 11.1

The text was updated successfully, but these errors were encountered:

I’m getting a similar error

then when I run

Oh, I figured it out. @scheung38 try adding this

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/digitalocean: provider registry registry.terraform.io does not have
a provider named registry.terraform.io/hashicorp/digitalocean

If you have just upgraded directly from Terraform v0.12 to Terraform v0.14
then please upgrade to Terraform v0.13 first and follow the upgrade guide for
that release, which might help you address this problem.

Did you intend to use digitalocean/digitalocean? If so, you must specify that
source address in each module which requires that provider. To see which
modules are currently depending on hashicorp/digitalocean, run the following
command:
terraform providers

I am using terraform 14.5 on Windows10

very simple code ..
provider «digitalocean» <
token = «XXXXXXXX»
>

resource «digitalocean_droplet» «mydroplet» <
image = «ubuntu-18-04-x64»
name = «web-1»
region = «sfo2»
size = «s-1vcpu-1gb»
>

Источник

Error: Failed to query available provider packages #25909

Terraform Version

Terraform Configuration Files

Debug Output

Expected Behavior

terraform init succeed

Actual Behavior

terraform init fails

Steps to Reproduce

The text was updated successfully, but these errors were encountered:

It still happens to me trying to user databricks provider. terraform creates a folder — and copies all its own providers to it, but it doesn’t copy other providers, for me its databricks

databrickslabs folder

workaround. manual copy the folder of the provider to — folder

Just need to think If you’re going to automate this, creating a scripts that copies the folder while this is fixed

Hi @dgonzalezp , thanks for reporting this and I’m sorry you’re experiencing this confusing behavior!

Terraform v0.13 pulls a list of providers from both the state and configuration when determining provider requirements — you can run terraform providers to see this in action. Terraform v0.12 has no concept of ‘namespaces’, so when it encounters a provider named «databricks» it queries a special «alises» table in the registry, which is where that odd-looking «-/databricks» (and other providers) come from. Since that provider is not a hashicorp provider, it’s unable to find it.

You can fix this by using the terraform state replace-provider command to update your statefile with the databricks providers’ source address :

terraform state replace-provider -/databricks registry.terraform.io/databrickslab/databricks

For anyone else interested in this issue, this information is in the upgrade guide, but rather hard to find in the in-house providers section.

Источник

Error: Failed to query available provider packages #26200

Trying to run terraform init and getting the following error message:

> 2.53″. Error: Failed to query available provider packages Could not retrieve the list of available versions for provider hashicorp/aws: no available releases match the given constraints 3.5.0,

The following are my config files.

providers.tf

> 3.5.0″ region = «eu-west-2» shared_credentials_file = «

And versions.tf

I’ve searched online for solutions and tried a couple of things from the documentation and git but always get the same error. Any help is appreciated.

The text was updated successfully, but these errors were encountered:

I am having this same issue. I booted up a fresh, clean install of Ubuntu, installed Terraform 0.13.2, and did a few tests. I used the following simple configuration:

When I run terraform init , everything works fine.

Then, I upgrade the aws provider version to 3.5.0 and run terraform init and again, everything is fine:

HOWEVER: If I run the same tests above, but this time with the following in

/.terraformrc , I run into trouble:

First, let’s clean up from past tests:

Running terraform init again yields:

We can see that the aws provider was installed to a common location and symlinked:

Now, if I upgrade the provider version to 3.5.0, chaos ensues:

@LunaticZorr Your provider constraints are unsatisfiable. It looks like you have multiple constraints, probably in several locations in your configuration. 3.5.0 and

> 3.5.0 are compatible, but,

> 2.53 basically means > 2.0.0, . As you can imagine, you can’t install a provider version which is both equal to 3.5.0 and .

The fix for this is to find which module or file contains the additional version constraint, and update it so that all of them are compatible.

I hope this explains the problem you’re seeing. This does not seem to be a bug in Terraform, so I’m going to close this issue.

@jcarlson The plugin cache problem you’re seeing seems to be separate, and I can reproduce it. Please report it as another issue so that it can be investigated. Thanks in advance!

Источник

Troubleshooting the Terraform Provider

This topic describes how to troubleshoot common Oracle Cloud Infrastructure ( OCI ) Terraform provider issues.

Start with Troubleshooting Basics and then refer to the following sections:

Troubleshooting Basics

When troubleshooting or getting support for the Oracle Cloud Infrastructure ( OCI ) Terraform provider, it is often useful to first check the status of the OCI services, the version of Terraform and the provider, and enable and collect verbose logging.

Tip

Checking service status and verbose log output can help you determine whether an issue is related to the Terraform provider or the OCI service the provider is using.

Refer to the list of common issues after you start with the basics.

Checking OCI Service Status and Outages

To check on the latest status and whether there are any outages in OCI , see OCI Status.

Checking the Terraform and OCI Terraform Provider Versions

To verify the version of Terraform and the OCI Terraform provider, initialize Terraform from a directory with your configurations and then run the -version command. For example:

The versions are displayed:

Tip

Newer versions of the OCI Terraform provider include the version of the provider in error messages.

The OCI Terraform provider documentation reflects the latest version. You can view documentation for earlier provider versions by visiting the HashiCorp reference and selecting a specific version. You can also download and install a specific version of the provider.

Verbose Logging for OCI Terraform Provider

To get verbose console output when the provider is running, precede your Terraform command with the TF_LOG and OCI_GO_SDK_DEBUG flags. For example:

The TF_LOG level and OCI_GO_SDK_DEBUG flags can also be set as environment variables.

Automatic Retries

While applying, refreshing, or destroying a plan, Terraform may encounter some intermittent OCI errors (such as 429 or 500 errors) that could succeed on retry. By default, the OCI Terraform provider automatically retries such operations for up to 10 minutes. The following fields can be specified in the provider block to further configure the retry behavior:

• disable_auto_retries — Disable automatic retries for retriable errors.
• retry_duration_seconds — The minimum duration (in seconds) to retry a resource operation in response to HTTP 429 and HTTP 500 errors. The actual retry duration may be slightly longer due to jittering of retry operations. This value is ignored if the disable_auto_retries field is set to true .

Concurrency Control Using Retry Backoff and Jitter

To alleviate contention between parallel operations against OCI services; the OCI Terraform provider schedules retry attempts using quadratic backoff and full jitter. Quadratic backoff increases the maximum interval between subsequent retry attempts, while full jitter randomly selects a retry interval within the backoff range.

For example, the wait time between the first and second retry attempts is chosen randomly between 1 and 8 seconds. The wait time between the second and third retry attempts is chosen randomly between 1 and 18 seconds. Regardless of the number of retry attempts, the retry interval time is capped after the 12th attempt at 288 seconds.

Note that the retry_duration_seconds field only affects retry duration in response to HTTP 429 and 500 errors; as these errors are more likely to result in success after a long retry duration. Other HTTP errors (such as 400, 401, 403, 404, and 409) are unlikely to succeed on retry. The retry_duration_seconds field does not affect the retry behavior for such errors.

Common Issues

Note

Resources Are Destroyed When Applying Changes

Existing OCI resources might be destroyed and re-created when Terraform configurations attempt to update a resource property that is not updatable. Terraform warns you when changes will destroy a resource. Always run terraform plan before applying changes to see what resources will be affected. See Destructive Changes for more information.

Dependent Resource Cannot Be Updated

Sometimes, an update to an OCI resource should force the resource to be destroyed and re-created, but another resource’s dependency on the resource disallows the operation.

For example, you might want to make an update to an oci_core_instance_configuration resource, but an instance pool uses that instance configuration. The instance configuration cannot be deleted because the instance pool references it in a required argument.

To work around this type of behavior, you can use the lifecycle and create_before_destroy meta-arguments in the resource block.

In this example, Terraform creates a second oci_core_instance_configuration resource that includes your updates, then assigns the new instance configuration to the related instance pool. Finally, Terraform destroys the original instance configuration. For example:

Resource Cannot Be Destroyed or Updated

You can prevent an OCI resource from being destroyed by including the lifecycle and prevent_destroy = true meta-arguments in the resource block of your Terraform configuration file. The following configuration, for example, results in an Object Storage bucket that cannot be destroyed:

This meta-argument prevents the use of terraform destroy . Because certain configuration updates require resources to be destroyed before they can be applied, this setting can make some updates impossible to apply as well. In this example, name is a property that cannot be updated without destroying and re-creating the resource. Therefore, you cannot update the name of the bucket without removing or changing the lifecycle meta-argument.

Resource Argument Cannot Be Unset

Many Oracle Cloud Infrastructure resources managed by the OCI Terraform provider accept configuration arguments that are optional. Once set, whether during resource creation or a subsequent update, these arguments cannot be unset by passing an empty string or removing the argument from the configuration. Attempts to unset these arguments are ignored by Terraform.

The full reference of the OCI Terraform provider’s supported resources and data sources contains usage, argument, and attribute details. The full reference is available at docs.oracle.com and Terraform Registry.

Data sources and resources are grouped by service within the reference.

Referencing Triggers in Lifecycle Meta-arguments

Terraform v0.14 and later might require that you replace global variables in your configuration files with a combination of local variables and triggers. To reference a trigger in lifecycle and ignore_changes meta-arguments and avoid executing the configuration on subsequent Terraform apply operations, reference the trigger as follows:

Cannot Delete Compartment

By default, the Terraform provider does not delete a compartment when using the destroy command.

You must set the enable_delete argument to true for the provider to attempt to delete the compartment. For example:

Note

To destroy a compartment, the compartment must also be empty. Use the depends_on argument to ensure that any hidden dependencies are defined. See Resources for more information.

«Operation Timeout» Error

If the Terraform CLI returns an error message like the following:

Then the specified OCI service is indicating that the resource has not yet reached the expected state after polling for some time.

You may need to increase the operation timeout for your resource to continue polling for longer. See Operation Timeouts for details on how to do this.

«Unexpected LifeCycle state» Error

If the Terraform CLI returns an error message like the following:

Then the specified OCI service encountered an unknown error. Retry, or contact support regarding that service.

Terraform CLI Issues

This section contains information dealing with the installation and configuration of the Terraform CLI.

«No such file» Error After Upgrading the OCI Terraform Provider

If the Terraform CLI returns an error message like the following:

You are likely using a version of the OCI Terraform provider that is not compatible with the Terraform binary you have installed. For OCI Provider versions v3.x.x and above, a minimum Terraform version of v.0.10.1 is required.

«TCP. i/o timeout» Message When Connecting Via Proxy

If the Terraform CLI returns an error message like the following:

Then you may not have properly configured your proxy settings. The OCI Terraform provider supports http_proxy , https_proxy and no_proxy variables where the inclusion or exclusion lists can be defined as follows:

If the Terraform CLI returns an error message like the following:

Ensure that Terraform is using trusted TLS certificates and the certificate chain is valid. See Terraform runs failing with «x509: certificate signed by unknown authority» error for more information. If using MacOS Catalina, refer to the MacOS section of the document for more specifics on resolving certificate issues.

«Outdated GPG key. unable to verify new provider releases» Error Message

If the Terraform CLI returns an error message like the following:

This message means that the Terraform registry is omitting the Terraform provider versions signed by a new GPG key. The Terraform CLI will install the last version of the OCI Terraform provider that it can successfully verify, which might not be the latest version.

To remove this message and ensure you can use the latest version of the OCI Terraform provider, upgrade the Terraform CLI to the latest maintenance release available for the major Terraform version you are using. For example, if you are using Terraform v0.12.21, upgrade to the lastest available version of v0.12.

Terraform Provider Issues

This section contains information related to the installation and configuration of the OCI Terraform provider.

«NotAuthenticated» Error When Using Terraform

If the Terraform CLI returns an error message like the following:

• Verify you have properly set user_ocid , tenancy_ocid , fingerprint and private_key_path .
• Verify your private_key_path is pointing to your private key and not the corresponding public key.
• Verify you have added the corresponding public key to the user account you have specified with user_ocid .
• Verify the public/private key pairs you are using are of the correct format. See Required Keys for details on the correct format and how to generate keys.
• Verify the user account is part of a group with the appropriate permissions to perform the actions in the plan you are executing.
• Verify your Tenancy has been subscribed to the Region you are targeting in your plan.

«Can not create client, bad configuration: did not find a proper configuration for tenancy» Message When Using Aliases

If the Terraform CLI returns a message like this, it might indicate an issue with your environment:

If your provider configuration includes an alias, your resources should explicitly specify the provider alias using provider = «oci.alias_name» . If a resource does not use the alias to specify the provider, Terraform creates a default provider to use with such resources. The default provider loads configuration values from environment variables or the

/.oci/config file. These values may differ from those used by your aliased provider and cause the configuration error.

Either remove the alias in your provider configuration, or ensure that every resource specifies the provider by the proper alias. Read more about using alias in the official Terraform documentation, and see Configuring the Provider for more information about how Terraform uses environment variables and the OCI config file.

«Field cannot be set» Error Message

If the Terraform CLI returns an error message like the following:

You are likely using an older version of the OCI Terraform provider and the field you are trying to set was released in a later version. Use the following command to check your Terraform provider version.

The OCI Terraform provider documentation reflects the latest version.

«Could not get info about the first DbHome in the dbSystem» Error Message When Importing db_home

If the oci_database_db_system being imported is missing a primary db_home , an empty placeholder for db_home is set in the Terraform state file. To keep configurations consistent with the imported state, add an empty placeholder for db_home to your configuration. For example:

The full reference of the OCI Terraform provider’s supported resources and data sources contains usage, argument, and attribute details. The full reference is available at docs.oracle.com and Terraform Registry.

Data sources and resources are grouped by service within the reference.

«Failed to query available provider packages» Error Message When Running Resource Discovery

If the Terraform CLI returns an error message like the following when using resource discovery:

Then you can ensure that Terraform uses an existing local provider binary by specifying its location using the provider_bin_path environment variable. For example:

Terraform attempts to download the latest version of the OCI Terraform provider when you use resource discovery.

Default Tags Deleted on Apply

Sometimes, the OCI Terraform provider can unexpectedly delete existing tag defaults from a resource when running terraform apply . This issue affects the Oracle-Tags automatic tag defaults in particular.

To work around this issue, you can add the ignore_defined_tags attribute to your provider block.

The ignore_defined_tags attribute allows you to list out the keys of the defined tags that Terraform will ignore as part of plan or apply. The ignore_defined_tags attribute can only be specified at the provider level, and has a maximum allowed size of 100. The tags provided in this attribute are ignored for all the resources in that Terraform file.

In the following example, «Oracle-Tags.CreatedOn» and «Oracle-Tags.CreatedBy» are the keys in the defined_tags map associated with a remote resource:

For more information, see Provider Definitions and refer to the related GitHub issue.

Service API Errors

Because the Terraform provider interacts with OCI services on your behalf, many error messages surfaced by the Terraform provider come directly from OCI services. The API Errors reference lists common errors returned by all services.

Service error messages returned by the OCI Terraform provider include the following information:

• Error — the HTTP status and API error codes
• Provider version — the version of the OCI Terraform provider used to make the request
• Service — the OCI service responding with the error
• Error message — details regarding the error returned by the service
• OPC request ID — the request ID
• Suggestion — suggested next steps

This section details a few of the more commonly returned service errors.

«400-InvalidParameter» Error

If the Terraform CLI returns an error message like the following:

Update the parameter specified in the error message in the Terrform configuration for the resource.

The full reference of the OCI Terraform provider’s supported resources and data sources contains usage, argument, and attribute details. The full reference is available at docs.oracle.com and Terraform Registry.

Data sources and resources are grouped by service within the reference.

«400-LimitExceeded» Error

While using Terraform, you might encounter errors indicating that you have reached or exceeded the service limits for a resource. For example:

To understand more about your OCI service limits and how to request a limit increase, see Service Limits

«404-NotAuthorized» Error

If the Terraform CLI returns an error message like the following:

Verify the user account is part of a group with the appropriate permissions to perform the actions in the plan you are executing. Refer to the Policy Reference for your service for more information.

«500-InternalError» Error

If the Terraform CLI returns an error message like the following:

The service responded to the request from the Terraform provider with an internal error. If you contact support for this issue, reference the information in the message.

Источник

#terraform #terraform-provider-azure

Вопрос:

Я создал main.tf файл, как показано ниже, для модуля terraform Mongodb.

 resource "mongodbatlas_teams" "test" {
  org_id     = null
  name       = "MVPAdmin_Team"
  usernames  = ["user1@email.com", "user2@email.com", "user3@email.com"]
}

resource "mongodbatlas_project" "test" {
  name   = "MVP_Project"
  org_id = null

  teams {
    team_id    = null
    role_names = ["GROUP_CLUSTER_MANAGER"]

  }
  
}
resource "mongodbatlas_project_ip_access_list" "test" {
  project_id = null
  ip_address = null
  comment    = "IP address for MVP Dev cluster testing"
}

resource "mongodbatlas_cluster" "test" {
  name                = "MVP_DevCluster"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  cluster_type        = REPLICASET
  state_name          = var.state_name
  replication specs {
     num_shards= var.num_shards
     region_config {
       region_name = "AU-EA"
       electable_nodes = var.electable_nodes
       priority        = var.priority
       read_only_nodes = var.read_only_nodes
     }  
  }

  provider_backup_enabled = var.provider_backup_enabled
  auto_scaling_disk_gb_enabled = var.auto_scaling_disk_gb_enabled
  mongo_db_major_version = var.mongo_db_major_version
  provider_name = "Azure"
  provider_disk_type_name = var.provider_disk_type_name
  provider_instance_size_name = var.provider_instance_size_name



  mongodbatlas_database_user {
    username = var.username
    password = var.password
    auth_database_name = var.auth_database_name
    role_name = var.role_name
    database_name = var.database_name
  }
  mongodbatlas_database_snapshot_backup_policy {
    policy_item = var.policy_item
    frequency_type = var.frequency_type
    retention_value = var.retention_value
  
 }

 advanced_configuration {
      minimum_enabled_tls_protocol = var.minimum_enabled_tls_protocol
   no_table_scan                  = var.no_table_scan
   connection_string              = var.connection_string

 } 
}
 

Тем не менее, terraform init сообщает, как показано ниже:

 $ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/mongodbatlas...

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/mongodbatlas: provider registry registry.terraform.io does not have
a provider named registry.terraform.io/hashicorp/mongodbatlas

If you have just upgraded directly from Terraform v0.12 to Terraform v0.14
then please upgrade to Terraform v0.13 first and follow the upgrade guide for
that release, which might help you address this problem.

Did you intend to use mongodb/mongodbatlas? If so, you must specify that
source address in each module which requires that provider. To see which
modules are currently depending on hashicorp/mongodbatlas, run the following
command:
    terraform providers 

 

Есть какие-нибудь идеи относительно того, что происходит не так?

Комментарии:

1. Вы недавно перешли с одной версии Terraform на более новую? Попробуйте добавить что-то подобное в свой tf-файл(ы): registry.terraform.io/providers/mongodb/mongodbatlas/latest/…

Ответ №1:

В сообщении об ошибке объясняется наиболее вероятная причина появления этого сообщения об ошибке: вы выполнили обновление непосредственно с Terraform v0.12 до Terraform v0.14 без выполнения шагов обновления Terraform v0.13.

Если вы сначала обновитесь до Terraform v0.13 и выполните эти инструкции, то средство обновления сможет дать более конкретные инструкции о том, что здесь нужно изменить, и, возможно, даже сможет автоматически обновить вашу конфигурацию для вас.

Однако, если вы хотите, вы также можете вручную добавить блок конфигурации, который вставил бы инструмент обновления версии 0.13, чтобы указать, что вы собираетесь использовать mongodb/mongodbatlas поставщика как «mongodbatlas» в этом модуле:

 terraform {
  required_providers {
    mongodbatlas = {
      source = "mongogdb/mongodbatlas"
    }
  }
}
 

В руководстве по обновлению версии 0.13 есть некоторые другие соображения, которые не рассматриваются выше, поэтому вам все равно может потребоваться выполнить действия, описанные в этом руководстве по обновлению, если вы увидите другие сообщения об ошибках после выполнения того, что я показал выше.

Комментарии:

1. Извиняюсь, приятель, но я не менял версию TF. Я, конечно, попробую ваше предложение. Большое спасибо!

2. Спасибо за помощь! Просто дружеское уведомление: у вас есть опечатка в monogdb/mongodbatlas, она должна быть: source = «mongodb/mongodbatlas»

Edit: I fixed this — it was something stupid. I misnamed some AWS resources so it was looking for those extra providers as a result. Oops.

Lesson for any future people: check your resource names!

I really don’t understand what’s happening here. The only provider I’m using is AWS to set up a basic VPC and web server:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "3.52.0"
    }
  }
}

provider "aws" {
    region  = "us-east-1"
    access_key = var.aws_access_key
    secret_key = var.aws_secret_key
}

… VPC/other config

When I try to run terraform init, I get the following:

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching "3.52.0"...
- Finding latest version of hashicorp/internet...
- Finding latest version of hashicorp/main...
- Installing hashicorp/aws v3.52.0...
- Installed hashicorp/aws v3.52.0 (signed by HashiCorp)
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/internet: provider registry
│ registry.terraform.io does not have a provider named registry.terraform.io/hashicorp/internet
│
│ All modules should specify their required_providers so that external consumers will get the correct providers
│ when using a module. To see which modules are currently depending on hashicorp/internet, run the following
│ command:
│     terraform providers
╵

╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/main: provider registry
│ registry.terraform.io does not have a provider named registry.terraform.io/hashicorp/main
│
│ All modules should specify their required_providers so that external consumers will get the correct providers
│ when using a module. To see which modules are currently depending on hashicorp/main, run the following command:
│     terraform providers
╵

terraform-providers output:

Providers required by configuration:

    .
    ├── provider[registry.terraform.io/hashicorp/aws] 3.52.0
    ├── provider[registry.terraform.io/hashicorp/internet]
    └── provider[registry.terraform.io/hashicorp/main]

I’m on v1.0.3. I’ve tried a reset/reinstall of terraform here and a clean slate of hidden files. What surprises me is that another file I have initializes fine and also only uses AWS as a provider. What are these hashicorp/internet and hashicorp/main providers and why can’t it seem to find them? My other file that initiates correctly doesn’t try to pull those two extra providers.