I assume I am using the latest version of azurerm:
provider "azurerm" {
version = "=2.34.0"
features {}
}
As soon as I add this resource to my tf script:
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/policy_assignment
I get this error when I do terraform init:
>terraform init
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/custom...
- Finding hashicorp/azurerm versions matching "2.34.0"...
- Installing hashicorp/azurerm v2.34.0...
- Installed hashicorp/azurerm v2.34.0 (signed by HashiCorp)
Error: Failed to install provider
Error while installing hashicorp/custom: provider registry
registry.terraform.io does not have a provider named
registry.terraform.io/hashicorp/custom
Am I missing any custom terraform provider? Looking at the Terraform documentation in the link above, I expect the azurerm_policy_definition resource must be included n the azurerm
Thanks to #ChristianPearce who deserves the credit for the answer.
This is a common and potentially misleading error.
There could me many scripting issues that cause this error.
In my case my resource name had typo in it like below:
resource "azurerm_virtual_network_typo_in_type" "main" {
This could also be a problem with terraform sub-modules as discussed in https://github.com/hashicorp/terraform/issues/25602.
For community providers, every module requires a required_providers block with an entry specifying the provider source.
So basically you need to have this in all your modules and in your main tf-script (replace the custom-prov-name by you actual provider):
terraform {
required_providers {
custom-prov-name = {
source = ".../custom-prov-name"
}
}
}
Related
When I ran init:
Initializing modules...
Initializing the backend...
Initializing provider plugins...
Finding cloudflare/cloudflare versions matching "~> 3.0"...
Finding latest version of hashicorp/cloudflare...
Installing cloudflare/cloudflare v3.31.0...
Installed cloudflare/cloudflare v3.31.0 (signed by a HashiCorp partner, key ID DE413CEC881C3283)
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/cloudflare: provider registry registry.terraform.io does not have a provider named
registry.terraform.io/hashicorp/cloudflare
Did you intend to use cloudflare/cloudflare? If so, you must specify that source address in each module which requires that provider. To see which modules are currently
depending on hashicorp/cloudflare, run the following command:
terraform providers
Module:
cat dns.tf
module "dns" {
source = "./dns"
}
Definition:
cat cloudflare.tf
terraform {
required_providers {
cloudflare = {
source = "cloudflare/cloudflare"
version = "~> 3.0"
}
}
}
provider "cloudflare" {
email = "CLOUDFLARE_EMAIL"
api_key = "CLOUDFLARE_API_KEY"
}
I want to deploy this portion of code about azure frontdoor :
`
resource "azurerm_cdn_frontdoor_profile" "example" {
name = "example-cdn-profile"
resource_group_name = "frdoor-p-to-01"
sku_name = "Standard_AzureFrontDoor"
tags = {
environment = "Production"
}
}
`
But when i run the pipeline, i have this problem :
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider
│ hashicorp/azurerm: no available releases match the given constraints ~>
│ 3.27.0, 3.28.0
#--------------------------------------------------
I use a VM hosted agent (linux)
I try to modify the provider file to the another version but the same error.
Some one have a solution please ?
`
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
#version = "~> 3.27.0"
version = "=3.28.0"
#version = "=2.97.0"
}
`
I use a VM Hosted agent where terraform is installed and azure devops pipeline.
This error suggests that you have two modules in your configuration with contradictory version constraints: it isn't possible to require both exactly 3.28.0 and exactly 3.27.0 at the same time.
You can use the terraform providers command to learn which version constraints are specified in which of your modules. To proceed with this change you will need to make sure that there is at least one version that all of your modules declare that they are compatible with.
To avoid situations like this, it's better to only use lower-bound version constraints >= in your shared modules, declaring the minimum version that the module has been tested with, and leave the upper bound unspecified unless you already know that the module is incompatible with a later provider version. This means you can then gradually upgrade the provider without having to update the version constraints across all of your modules in lockstep.
The dependency lock file is the correct place to record exact version selections, and Terraform generates that automatically during terraform init so you do not need to edit it yourself. If you are using only >= constraints in your modules then you can run terraform init -upgrade whenever you wish to upgrade to the latest compatible version of each provider.
My main.tf file starts with
terraform {
required_version = ">= 0.13.7"
required_providers {
aws = {
source = "hashicorp/aws"
version = "= 2.32.0"
}
foobar = {
source = "terraform.foo.com/foo/bar"
}
}
}
The catch here is that foo/bar is the module I'm developing locally so I also has this terraformrc file:
provider_installation {
dev_overrides {
"terraform.foo.com/foo/bar" = "/Users/appuser/foobar/bin/darwin-amd64"
}
}
Here's the errors I run into when running ✗ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/aws versions matching "2.32.0"...
- Finding latest version of terraform.foo.com/foo/bar...
Warning: Provider development overrides are in effect
The following provider development overrides are set in the CLI configuration:
- "terraform.foo.com/foo/bar" = "/Users/appuser/foobar/bin/darwin-amd64"
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 2.32.0
Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider
"terraform.foo.com/foo/bar": no available releases
match the given constraints
Update: when I remove terraformrc it does seem to work but I am not able to load the 2nd provider this way (since it relies on override):
terraform init
Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/aws versions matching "2.32.0"...
- Finding latest version of hashicorp/foo/bar...
- Installing hashicorp/aws v2.32.0...
- Installed hashicorp/aws v2.32.0 (self-signed, key ID 34365D9472D7468F)
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/plugins/signing.html
Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider
hashicorp/foo/bar: provider registry registry.terraform.io does not
have a provider named registry.terraform.io/hashicorp/foo/bar
The dev_overrides setting is, in spite of being placed inside the provider_installation block due to its thematic similarity, actually a runtime setting rather than an installation setting. Specifically, it asks Terraform to ignore whatever version of the provider terraform init previously selected and to use the given overridden provider instead.
Unfortunately, this model only works well if you're overriding a provider that already has at least one published version available, so that terraform init can select and install that version but then terraform apply (for example) can then ignore what terraform init installed, and use the override instead. (Terraform behaves this way because part of terraform init's responsibility is to update the Dependency Lock File, and so it needs to find at least one selectable version of each provider in order to produce a complete lock file.)
One way you could avoid this design quirk is to place a fake "release" of this provider in a local directory that you'd then configure as a filesystem mirror for that provider, in your .terraformrc file.
For example, if you create a directory /tmp/tf-workaround/terraform.foo.com/foo/bar/0.0.1/darwin_amd64 and place into it an empty file named terraform-provider-bar then that should be sufficient for terraform init to detect this as an available "published" version of the provider if given an CLI configuration like this:
provider_installation {
dev_overrides {
"terraform.foo.com/foo/bar" = "/Users/appuser/foobar/bin/darwin-amd64"
}
filesystem_mirror {
path = "/tmp/tf-workaround"
include = ["terraform.foo.com/foo/bar"]
}
direct {
exclude = ["terraform.foo.com/foo/bar"]
}
}
terraform init should then find the placeholder empty file and "install" it into .terraform/providers as normal. That empty file won't actually work as a valid plugin, but that's okay because terraform apply will ignore it anyway and will use the directory given in dev_overrides instead.
However, the dependency lock file will contain an incorrect entry for terraform.foo.com/foo/bar after installation, so if you intend to commit this test configuration to version control then you may wish to manually remove that block to reduce confusion once there really is a release of this provider.
The less-complex way to work here is to test a provider during development with a configuration that only includes that provider, and wait until you've actually published the provider somewhere before you use it "for real" as part of a larger system. In that case, you'd typically skip running terraform init altogether because the only external dependency would be the overridden provider, and so nothing additional would need to be installed.
The fix (which was to add direct {}) was found in TF docs:
provider_installation {
# Use /home/developer/tmp/terraform-null as an overridden package directory
# for the hashicorp/null provider. This disables the version and checksum
# verifications for this provider and forces Terraform to look for the
# null provider plugin in the given directory.
dev_overrides {
"hashicorp/null" = "/home/developer/tmp/terraform-null"
}
# For all other providers, install them directly from their origin provider
# registries as normal. If you omit this, Terraform will _only_ use
# the dev_overrides block, and so no other providers will be available.
direct {}
}
Actually I'm still getting
Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider
hashicorp/foo/bar: could not connect to hashicorp: Failed
to request discovery document: Get
"https://hashicorp/.well-known/terraform.json": dial tcp: lookup hashicorp on
100.217.9.1:53: no such host
We've been using older versions of both Terraform and the azurerm provider and I'm trying to update the code for newer (for us) versions of each, in this case:
Terraform: v0.13.7
azurerm: v2.25
As part of the recoding, I'm switching to using the Terraform provider block:
terraform {
required_version = "~> 0.13"
required_providers {
azurerm = {
version = "= 2.25.0"
source = "hashicorp/azurerm"
}
}
}
provider azurerm {
skip_provider_registration = true
features {}
}
Terraform is downloading v2.25 of the provider but also the most version v2.67:
$ terraform init
Initializing the backend...
Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Finding hashicorp/azurerm versions matching "2.25.0"...
- Finding latest version of -/azurerm...
- Installing hashicorp/azurerm v2.25.0...
- Installed hashicorp/azurerm v2.25.0 (signed by HashiCorp)
- Installing -/azurerm v2.67.0...
- Installed -/azurerm v2.67.0 (signed by HashiCorp)
So far this doesn't seem to be an issue, but I cannot understand why it's downloading multiple versions. Could it be because, in another code file which defines the backend (we use Azure storage for Terraform state), it's seeing that "azurerm" reference and treating it as a "new" one?
terraform {
backend azurerm {
container_name = "terraforminfra-v2"
key = "state/postgres.tfstate"
}
}
OK, I figured it out ... the "old" reference to the provider was still in the Terraform state, which I think is what was triggering the download of the most current version.
Terraform 0.13 just came out (https://www.hashicorp.com/blog/announcing-hashicorp-terraform-0-13/) and it changes how to work with 3rd party providers (https://www.terraform.io/upgrade-guides/0-13.html#explicit-provider-source-locations).
I'm encountering an error when running terraform init:
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/ibm...
Error: Failed to install provider
Error while installing hashicorp/ibm: provider registry registry.terraform.io
does not have a provider named registry.terraform.io/hashicorp/ibm
This used to work before with Terraform 0.12.29 and the IBM provider 1.10.0.
Here are the instructions for Linux and the current versions of Terraform and the IBM provider:
Install Terraform
Download Terraform 0.13
wget https://releases.hashicorp.com/terraform/0.13.0/terraform_0.13.0_linux_amd64.zip
Unzip the provider
unzip terraform_0.13.0_linux_amd64.zip
Move it to a folder in your path, such as:
mv terraform /usr/local/bin/
Ensure the version is 0.13
terraform version
Install the IBM provider
Create the folder where the plugin will be put:
mkdir -p ~/.terraform.d/plugins/localdomain/provider/ibm/1.10.0/linux_amd64
Get the provider:
wget https://github.com/IBM-Cloud/terraform-provider-ibm/releases/download/v1.10.0/terraform-provider-ibm_1.10.0_linux_amd64.zip
Unzip the provider:
unzip terraform-provider-ibm_1.10.0_linux_amd64.zip
Move the provider to the folder previously created:
mv terraform-provider-ibm_v1.10.0 ~/.terraform.d/plugins/localdomain/provider/ibm/1.10.0/linux_amd64
Test with a simple Terraform file
Create main.tf
terraform {
required_providers {
ibm = {
source = "localdomain/provider/ibm"
version = "1.10.0"
}
}
}
variable ibmcloud_api_key {
}
provider "ibm" {
ibmcloud_api_key = var.ibmcloud_api_key
}
resource ibm_resource_group new_group {
name = "created-by-terraform"
}
Create terraform.tfvars and fill in your IBM Cloud API key:
ibmcloud_api_key="REPLACE_WITH_YOUR_KEY"
Initialize Terraform
terraform init
will result in:
Initializing the backend...
Initializing provider plugins...
- Finding localdomain/provider/ibm versions matching "1.10.0"...
- Installing localdomain/provider/ibm v1.10.0...
- Installed localdomain/provider/ibm v1.10.0 (unauthenticated)
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.
And apply
terraform apply
will result in:
...
Enter a value: yes
ibm_resource_group.new_group: Creating...
ibm_resource_group.new_group: Creation complete after 2s [id=2142c8122344458d59b8729708464a]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Happy terraforming!
The IBM Provider is now published to the repository so you can use the new terraform 13 provider syntax such as:
terraform {
required_version = ">= 0.13"
required_providers {
ibm = {
source = "IBM-Cloud/ibm"
version = "1.11.2"
}
}
}
terraform {
required_version = ">= 0.13.3"
required_providers {
ibm = {
source = "ibm-cloud/ibm"
version = "1.12.0"
}
}
}
This will give you the latest version.