Terraform-provider-digitalocean: Error finding provider registry.terraform.io/hashicorp/digitalocean

Created on 19 May 2021  ยท  5Comments  ยท  Source: digitalocean/terraform-provider-digitalocean

Bug Report

Hello,

I ran into an issue while working on migrating a terraform code base from GCP to DO. Similar issues have seemingly to have popped up a few times from what I found (in the References area at the bottom), albeit my issue is slightly different considering I already had the "solution code" in my provider information and it is still throwing an error.


Describe the bug

When I attempt to build a digitalocean_vpc, it errors out being unable to find the provider for this resource. It was my first module other than connecting via my API token. Hoping I don't run into similar issues with firewalls and droplets.

Affected Resource(s)

  • digitalocean_vpc

Expected Behavior

Terraform should have initialized.

Actual Behavior

Terraform Errored out claiming it couldn't find the provider for the vpc resource.

> terraform -v       
Terraform v0.15.3
on linux_amd64
> terraform init

Initializing modules...
- network in modules/network

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/digitalocean...
- Finding digitalocean/digitalocean versions matching ">= 2.8.0"...
- Installing digitalocean/digitalocean v2.8.0...
- Installed digitalocean/digitalocean v2.8.0 (signed by a HashiCorp partner, key ID F82037E524B9C0E8)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html
โ•ท
โ”‚ 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
โ”‚ 
โ”‚ 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
โ•ต



md5-48bec51bda30a4a7315feaf677e0dad9



terraform providers

Providers required by configuration:
.
โ”œโ”€โ”€ provider[registry.terraform.io/digitalocean/digitalocean] >= 2.8.0
โ””โ”€โ”€ module.network
    โ””โ”€โ”€ provider[registry.terraform.io/hashicorp/digitalocean]



md5-5284f6d18e1ce90a79eed695ec0dbf10



terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = ">= 2.8.0"
    }
  }
}
provider "digitalocean" {
  token = var.token
}



md5-7e6b16b8d891d30c45f68062330b0b07



module "network" {
    source  = "./modules/network"
    region   = var.region
}



md5-e52f1f021d5e0449ec7884ce978f8eca



resource "digitalocean_vpc" "valheimvpc" {
  name      = "valheim-vpc"
  region     = var.region
  ip_range = "10.10.10.0/24"
}

Expected behavior
Terraform initializes the resources needed from the DO provider.

Debug Output
https://gist.github.com/ElijahGartin/9474417826692d676a70c6004e9aa5b9

Panic Output
N/A

References
Issue 621
Issue 270

bug

All 5 comments

You need to add the terraform { required_providers { ... } } block to the module. It looks like Terraform is resolving hashicorp/digitalocean for the module instead of digitalocean/digitalocean. Using the required_providers block there would tell Terraform to explicitly use digitalocean/digitalocean instead.

Recall that Terraform modules are independent of each other, even if they share the same directory tree. The only provider-related configuration from the calling module that will be inherited by the called module is default provider configurations, and not the required_providers configuration. See https://www.terraform.io/docs/language/meta-arguments/module-providers.html#default-behavior-inherit-default-providers.

@tdyas - Thank you for your feedback. The default provider configurations are _supposed_ to be inherited if you do not explicitly define an alias provider. If the child module does not declare any configuration aliases, the providers argument is optional. If you omit it, a child module inherits all of the default provider configurations from its parent module. (Default provider configurations are ones that don't use the alias argument.)

I've successfully passed default provider configurations with AWS, Azure, and GCP without any problems since v0.11. For some reason with digitalocean provider, the inheritance breaks and even trying to define an alias just ends up throwing a bunch of errors. Adding the required providers and provider block again in the module did work while passing in the region and token parameters, however this seems to go against terraform default provider functioning and DRY programming principles.

I was also trying to find in the documentation for the DigitalOcean provider where it says that you must define the required providers in every module, but I could not find it. It may be good to add a section in the documentation explaining that if you are going to use modules in your terraform configuration that you need to force the required providers in each module's main file. https://registry.terraform.io/providers/digitalocean/digitalocean/latest/docs#example-usage

I understand your frustration, but this appears to be Terraform's standard behavior for any provider that is not maintained by Hashicorp. It is not specific to DigitalOcean.

I've successfully passed default provider configurations with AWS, Azure, and GCP without any problems since v0.11.

Your provider setups work for AWS, Azure, and GCP because those providers are maintained by Hashicorp. When you use any resources from those providers in a module and do not provide a terraform { required_providers { ... } } in that module, Terraform automatically infers the name of the provider as hashicorp/FOO (where FOO is aws, azure, or google). Note that Terraform inferred the name of the provider for your network module as hashicorp/digitalocean.

I would expect Terraform will do this inference for any provider that is not maintained by Hashicorp. Thus, this issue is not specific to DigitalOcean.

There is a difference between the provider requirement blocks (i.e., terraform { required_providers { ... } }) and provider configuration blocks (i.e., provider "digitalocean"). Only the configuration blocks are inherited; the provider requirements blocks are not.

Indeed, the Terraform documentation explicitly states:

Each Terraform module must declare which providers it requires, so that Terraform can install and use them. Provider requirements are declared in a required_providers block.

https://www.terraform.io/docs/language/providers/requirements.html

Your ability to _not_ provide that requirements block for Hashicorp-maintained providers (e.g., AWS, Azure, and GCP) is legacy behavior that Terraform is free to stop maintaining in a future version.

Moreover, by not using required_providers even for a provider like AWS, I surmise that you are not using a version bound. (At my company, all of our Terraform modules have a required_providers block for AWS, so we can set a version bound.)

I was also trying to find in the documentation for the DigitalOcean provider where it says that you must define the required providers in every module, but I could not find it.

I agree that is probably good to add.

Do you want to submit a PR? (I don't work for DigitalOcean, but have contributed much to this project in the past. @andrewsomething is diligent on reviewing PRs.)

This error message from Terraform itself seems to be pretty clear:

โ”‚ 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

This behavior isn't anything specific to the DigitalOcean provider. From the module developer docs:

Although provider configurations are shared between modules, each module must declare its own provider requirements

https://www.terraform.io/docs/language/modules/develop/providers.html#provider-version-constraints-in-modules

I've successfully passed default provider configurations with AWS, Azure, and GCP without any problems

This is likely because all of these providers are under the HashiCorp namespace in the registry (e.g. source = "hashicorp/google"). Terraform will fallback to looking for a HashiCorp provider, hence trying hashicorp/digitalocean.

I was also trying to find in the documentation for the DigitalOcean provider where it says that you must define the required providers in every module, but I could not find it. It may be good to add a section in the documentation explaining that if you are going to use modules in your terraform configuration that you need to force the required providers in each module's main file.

We don't currently have any DigitalOcean module specific documentation, but that might be a good idea.

Thank you @tdyas and @andrewsomething. I created a PR for this for dummies like me. :)

Linked: https://github.com/digitalocean/terraform-provider-digitalocean/pull/637

Was this page helpful?
0 / 5 - 0 ratings

Related issues

v0112358 picture v0112358  ยท  7Comments

benjamin-maynard picture benjamin-maynard  ยท  6Comments

alekgr picture alekgr  ยท  8Comments

hashibot picture hashibot  ยท  8Comments

Owpac picture Owpac  ยท  4Comments