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.
Related
I'm using terraform and terragrunt to create some repositories in bitbucket, and since they do not have an official provider I'm using one from DrFaust92/bitbucket. I have done everything in my computer and I could apply all, now I'm moving the workflow to circle ci, and when I run it there I always get this error:
bitbucket_repository.repository: Creating...
╷
│ Error: Empty Summary: This is always a bug in the provider and should be reported
to the provider developers.
│
│ with bitbucket_repository.repository,
│ on main.tf line 5, in resource "bitbucket_repository" "repository":
│ 5: resource "bitbucket_repository" "repository" {
The resource does not have anything in special:
resource "bitbucket_repository" "repository" {
name = var.name
description = var.description
owner = var.owner
project_key = var.project_key
language = var.project_language
fork_policy = var.fork_policy
is_private = true
}
I'm using terraform 1.3.7 and terragrunt 0.43.1 (in my computer and in circle ci, both run with the same versions). It fails when it access any tfstate: if the tfstate already exists, it throws the error when planning, if it doesn't, the plan runs well, but when I apply it fails with the same error.
Any help to fix this will be appreciated!
This is most likely issue associated with provider version. In your local, it may have a certain version downloaded/cached. Within Circle CI, it may be fetching latest provider that is available(which may have some issues). I would suggest you find the provider version currently in use locally, and then add required_providers block accordingly to make sure that it uses the same version of the provider. You can find the version presently in use from the terminal output that is generated on 'terraform init'. Below is the sample block to specify specific provider version(taken from: https://registry.terraform.io/providers/aeirola/bitbucket/latest/docs/resources/repository).
terraform {
required_providers {
bitbucket = {
source = "DrFaust92/bitbucket"
version = "v2.30.0"
}
}
}
I have below in my provider.tf in the root directory
terraform {
required_version = ">= 1.0.5"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "= 3.8.0"
}
mongodbatlas = {
source = "mongodb/mongodbatlas"
}
}
}
I am getting below error in terraform init stage
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
│
│ 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
After this error, I included below in my mongodb atlas child module too which needed it and it worked.
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas"
}
}
}
My question is why do I need to do this? I don't have to do it for any other required providers? Thanks in advance.
similar question is answered here - Terraform using both required_providers and provider blocks
gist - if the provider you are using is not one of the official provider by Terraform then you need to specify the terraform required_providers block to let terraform know the source to download the provider plugin.
LIST OF OFFICIAL PROVIDERS BY TERRAFORM -
https://registry.terraform.io/browse/providers?category=database%2Chashicorp%2Cinfrastructure-management%2Cpublic-cloud%2Casset%2Ccloud-automation%2Ccommunication-messaging%2Cvcs%2Cutility%2Cweb%2Csecurity-authentication%2Cplatform%2Clogging-monitoring%2Cnetworking%2Cinfrastructure%2Cdata-management%2Cci-cd%2Ccontainer-orchestration&tier=official
Just for visitors who are having the same error, follow the instructions
Check the message:
Did you intend to use mongodb/mongodbatlas? If so, you must specify
that source address in each module which requires that provider.
You need to put your MongoDB provider inside each module you're using.
Run terraform providers and check which modules require MongoDB.
Create a versions.tf file inside each module.
Add the following code (with your desired version):
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas",
version = "1.8.0"
}
}
}
About the need to put required_providers inside each module
Testing Atlas Provider Versions that are NOT hosted on Terraform Registry (i.e. pre-release versions)
To test development / pre-release versions of the Terraform Atlas
Provider that are not hosted on the Terraform Registry, you will need
to create a Terraform Provider Network Mirror.
The provider network mirror protocol is an optional protocol which you
can implement to provide an alternative installation source for
Terraform providers, regardless of their origin registries. Terraform
uses network mirrors only if you activate them explicitly in the CLI
configuration's provider_installation block. When enabled, a network
mirror can serve providers belonging to any registry hostname, which
can allow an organization to serve all of the Terraform providers they
intend to use from an internal server, rather than from each
provider's origin registry.
source: https://github.com/mongodb/terraform-provider-mongodbatlas
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
I am working on a Terraform configuration for a new project. The project consists of multiple microservices for which I've written modules. The project is supposed to be hosted on Digitalocean, so I installed the Terraform DigitalOcean Provider as a required provider:
# ./versions.tf
terraform {
required_version = ">= 0.14"
required_providers {
digitalocean = {
source = "digitalocean/digitalocean"
version = "2.3.0"
}
}
}
which is then 'initialized' in ./main.tf:
provider "digitalocean" {
token = var.do_token
}
However, when I try to run terraform init it fails because of error Error: Failed to query available provider packages.
terraform providers reveals that this happens because a module tries to require provider hashicorp/digitalocean instead of digitalocean/digitalocean:
├── provider[registry.terraform.io/digitalocean/digitalocean] 2.3.0
├── provider[registry.terraform.io/hashicorp/kubernetes] 1.13.3
├── provider[registry.terraform.io/hashicorp/kubernetes-alpha] 0.2.1
└── module.spaces
└── provider[registry.terraform.io/hashicorp/digitalocean]
I have tried to pass a the provider through the providers option in the module, but that didn't seem to make a difference:
module "spaces" {
source = "./Spaces"
providers = {
digitalocean = digitalocean
}
}
Is this a bug within Terraform 0.14 perhaps, or am I just misunderstanding?
Thanks.
It's failing when it's used in a submodule because you only have the required_providers configuration at the top level, you need to add it in each module.
This is explained in detail in this thread
The provider source needs to be declared in each module because an
interesting side effect of the provider source work is that we can now
use multiple providers with the same name in configuration. Each
module could use a provider named 'dns' with a different source.
Internally, terraform uses the source to create a FQN (fully-qualified
name) for each provider, so you could have for example three modules,
each using one of "mildwonkey/dns" "hashicorp/dns" and "yourname/dns".
Does anyone know if it is possible to have a Terraform script that uses multiple provider versions?
For example azurerm version 2.0.0 to create one resource, and 1.4.0 for another?
I tried specifying the providers, as documented here: https://www.terraform.io/docs/configuration/providers.html
However it doesn't seem to work as it tries to resolve a single provider that fullfills both 1.4.0 and 2.0.0.
It errors like:
No provider "azurerm" plugins meet the constraint "=1.4.0,=2.0.0".
I'm asking this because we have a large Terraform codebase and I would like to migrate bits by bits if doable.
There used to be a similar question raised, here: Terraform: How to install multiple versions of provider plugins?
But it got no valid answer
How to use multiple version of the same Terraform provider
This allowed us a smooth transition from helm2 to helm3, while enabling new deployments to use helm3 right away, therefore reducing the accumulation of tech debt.
Of course you can do the same for most providers
How we've solved this
So the idea is to download a specific version of our provider (helm 0.10.6 in my case) and move it to one of the filesystem mirrors terraform uses by default. The key part is the renaming of our plugin binary. In the zip we can find terraform-provider-helm_v0.10.6, but we rename it to terraform-provider-helm2_v0.10.6
PLUGIN_PATH=/usr/share/terraform/plugins/registry.terraform.io/hashicorp/helm2/0.10.6/linux_amd64
mkdir -p $PLUGIN_PATH
curl -sLo_ 'https://releases.hashicorp.com/terraform-provider-helm/0.10.6/terraform-provider-helm_0.10.6_linux_amd64.zip'
unzip -p _ 'terraform-provider-helm*' > ${PLUGIN_PATH}/terraform-provider-helm2_v0.10.6
rm _
chmod 755 ${PLUGIN_PATH}/terraform-provider-helm2_v0.10.6
Then when we declare our two provider plugins
We can use hashicorp/helm2 plugin from the filesystem mirror, and let terraform directly download the latest hashicorp/helm provider, which uses helm3
terraform {
required_providers {
helm2 = {
source = "hashicorp/helm2"
}
helm = {
source = "hashicorp/helm"
version = ">= 2.0.0"
}
}
}
# you will find the doc here https://registry.terraform.io/providers/hashicorp/helm/0.10.6/docs
provider "helm2" {
install_tiller = false
namespace = "kube-system"
kubernetes {
...
}
}
# you will find the doc at latest version https://registry.terraform.io/providers/hashicorp/helm/latest/docs
provider "helm" {
kubernetes {
...
}
}
When initializing terraform, you will find that
- Finding latest version of hashicorp/helm...
- Finding latest version of hashicorp/helm2...
- Installing hashicorp/helm v2.0.2...
- Installed hashicorp/helm v2.0.2 (signed by HashiCorp)
- Installing hashicorp/helm2 v0.10.6...
- Installed hashicorp/helm2 v0.10.6 (unauthenticated)
Using it
Its pretty straightforward from this point. By default, helm resources will pick our updated helm provider at v2.0.2. You must explicitly use provider = helm2 for old resources (helm_repositoryand helm_releases in our case). Once migrated, you can remove it to use the default helm provider.
No you cannot do what you want. Terraform expects your constraint to match one plugin version as eluded to in:
Plugin Names and Versions
If multiple versions of a plugin are installed, Terraform will use the
newest version that meets the configuration's version constraints.
So your constraint cannot be parsed to match anyone plugin, hence the error