Terraform: Module cannot find alias AWS provider in 0.12.0

Created on 27 May 2019  ยท  10Comments  ยท  Source: hashicorp/terraform

Hi,

I'm having problems upgrading to 0.12.0. We're running in eu-west-1 but one of my modules requires a cloudfront certificate that is only available in us-east-1.

The main terraform file defines an additional aws provider running in us-east-1 aliased to a name expected by the module.

When I follow the upgrade instructions, I get an error at the step when I run terraform plan against v0.12.

Error: Provider configuration not present

To work with module.sunset_environment.aws_acm_certificate.cloudfront its
original provider configuration at
module.sunset_environment.provider.aws.us_east_1 is required, but it has been
removed. This occurs when a provider configuration is removed while objects
created by that provider still exist in the state. Re-add the provider
configuration to destroy
module.sunset_environment.aws_acm_certificate.cloudfront, after which you can
remove the provider configuration again.

I don't understand what to do about this because provider.aws.us_east_1 is already defined.

Terraform Version

Upgrading 0.11.14 to 0.12.0

Terraform Configuration Files

provider "aws" {
  region  = local.aws_region
  version = "~> 2.12.0"
}

...

provider "aws" {
  alias   = "us_east_1"
  region  = "us-east-1"
  version = "~> 2.12.0"
}

...

module "sunset_environment" {
  source = "git::[email protected]:my-private-repo"

  dns_root_zone_id   = local.dns_root_zone_id
  dns_root_zone_name = local.dns_root_zone_name

  stage       = local.stage
  aws_region  = local.aws_region
  environment = local.environment

  vpc_id = local.vpc_id

  dns_public_zone_id   = local.dns_public_zone_id
  dns_public_zone_name = local.dns_public_zone_name

  external_lb_arn         = module.environment.external_lb_arn
  external_lb_dns_name    = module.environment.external_lb_dns_name
  external_lb_dns_zone_id = module.environment.external_lb_dns_zone_id

  external_lb_http_listener_arn  = module.environment.external_lb_http_listener_arn
  external_lb_https_listener_arn = module.environment.external_lb_https_listener_arn

  cdn_origin_ssl_protocols = ["TLSv1", "TLSv1.1", "TLSv1.2"]
}

... and from the module...

resource "aws_acm_certificate" "cloudfront" {
  provider = "aws.us_east_1"
  domain_name = "${local.site_cdn_fqdn}"
  validation_method = "DNS"
}

Debug Output

https://gist.github.com/npc-adrian/2b1b8e8a93060ea164d57a322baae6ea

Crash Output

N/A

Expected Behavior

terraform plan should run successfully and report no changes needed

Actual Behavior

An error occurred running a plan using 0.12. Same message twice as shown below.

Error: Provider configuration not present

To work with
module.sunset_environment.aws_acm_certificate_validation.cloudfront its
original provider configuration at
module.sunset_environment.provider.aws.us_east_1 is required, but it has been
removed. This occurs when a provider configuration is removed while objects
created by that provider still exist in the state. Re-add the provider
configuration to destroy
module.sunset_environment.aws_acm_certificate_validation.cloudfront, after
which you can remove the provider configuration again.


Error: Provider configuration not present

To work with module.sunset_environment.aws_acm_certificate.cloudfront its
original provider configuration at
module.sunset_environment.provider.aws.us_east_1 is required, but it has been
removed. This occurs when a provider configuration is removed while objects
created by that provider still exist in the state. Re-add the provider
configuration to destroy
module.sunset_environment.aws_acm_certificate.cloudfront, after which you can
remove the provider configuration again.

Steps to Reproduce

Following the instructions at https://www.terraform.io/upgrade-guides/0-12.html

Additional Context

Tried running 0.11 syntax (i.e. with interpolated strings) against 0.12 but got the same error.

I tried running the 0.12 upgrade command against the module but it can't resolve the us_east_1 provider. I guess that's expected but I figured it was worth a go.

References

Looks similar to #21416

bug core

Most helpful comment

looks like now you have to explicitly pass down the aliased providers to our modules explicitly. From the docs (https://www.terraform.io/docs/configuration/modules.html#passing-providers-explicitly):

Additional provider configurations (those with the alias argument set) are never inherited automatically by child modules, and so must always be passed explicitly using the providers map.

There's an example in the docs that I linked to, but what it comes down to is that in my module that issues certificates I have to declare that it expects to be told about an aliased AWS provider (note that it doesn't need to declare any configuration for this provider, just that it will be there). So, in some-module/main.tf:

provider "aws" {
  alias = "north-virginia"
}

and then when the module is used:

module "root_domain" {
  source = "./some-module"
  providers = {
    aws                = aws
    aws.north-virginia = aws.north-virginia
  }

  ...other stuff...
}

All 10 comments

I am also facing the same issue.

`
provider "aws" {
region = "eu-west-2"
profile = "dev"
alias = "dev-eu-west-2"
}

provider "aws" {
region = "eu-west-1"
profile = "dev"
alias = "dev-eu-west-1"
}
`

Then there are resource blocks within a module that report 'Provider configuration not present'. Happened straight after upgrading to 0.12

Happening to us as well. So far we have not been able to resolve this and have gone back to 0.11.

same issue

looks like now you have to explicitly pass down the aliased providers to our modules explicitly. From the docs (https://www.terraform.io/docs/configuration/modules.html#passing-providers-explicitly):

Additional provider configurations (those with the alias argument set) are never inherited automatically by child modules, and so must always be passed explicitly using the providers map.

There's an example in the docs that I linked to, but what it comes down to is that in my module that issues certificates I have to declare that it expects to be told about an aliased AWS provider (note that it doesn't need to declare any configuration for this provider, just that it will be there). So, in some-module/main.tf:

provider "aws" {
  alias = "north-virginia"
}

and then when the module is used:

module "root_domain" {
  source = "./some-module"
  providers = {
    aws                = aws
    aws.north-virginia = aws.north-virginia
  }

  ...other stuff...
}

looks like now you have to explicitly pass down the aliased providers to our modules explicitly. From the docs (https://www.terraform.io/docs/configuration/modules.html#passing-providers-explicitly):

Additional provider configurations (those with the alias argument set) are never inherited automatically by child modules, and so must always be passed explicitly using the providers map.

There's an example in the docs that I linked to, but what it comes down to is that in my module that issues certificates I have to declare that it _expects_ to be told about an aliased AWS provider (note that it doesn't need to declare any configuration for this provider, just that it will be there). So, in some-module/main.tf:

provider "aws" {
  alias = "north-virginia"
}

and then when the module is used:

module "root_domain" {
  source = "./some-module"
  providers = {
    aws                = aws
    aws.north-virginia = aws.north-virginia
  }

  ...other stuff...
}

This helped. Thank you. We were able to get the modules passing, or so we though, but we were getting errors about missing region configuration. I didn't like specifying regions multiple times. Saw your comment, made some changes to be more like what you posted and we were able to remove the duplicate region settings.

It sounds like some of you are upgrading from a Terraform version prior to 0.11 and so are running in to the provider-related changes introduced in Terraform 0.11.

The 0.12 upgrade guide is assuming you were coming from a working 0.11 configuration, so if you _are_ upgrading from 0.10 or earlier please be sure to review all of the intervening upgrade guides as well, and ideally upgrade by only one major version at a time so you can make sure things are working with one version before moving on to the next.

With that said, I know some of you are seeing the "Provider configuration not present" error for the first time after upgrading to Terraform 0.12 from a working 0.11 configuration, so it does seem like there's something unexpectedly different here, and we do intend to investigate further to see if something inadvertently changed relative to the 0.11 behavior.

It sounds like some of you are upgrading from a Terraform version prior to 0.11 and so are running in to the provider-related changes introduced in Terraform 0.11.

You're right, I found this under the terraform 0.10 -> 0.11 upgrade guide:

Action: In existing configurations where a descendent module inherits aliased providers from an ancestor module, use the new providers attribute to explicitly pass those aliased providers.

However, this wasn't actually _enforced_ in 0.11 (the aliased providers inherited just fine), so we never made that change during the migration either because we missed it in the guide or we just stopped checking things in the guide when all the errors were fixed.

I suspect the fact that this went un-enforced is why people are now encountering this error for the first time, even when upgrading directly from 0.11 -> 0.12 and so are stumped that it's not in this round of upgrade notes. I'd suggest that maybe it's worth adding a note in the upgrade guide this time around that this change is now _enforced_, possibly with an example like I gave above. Thoughts?

@eviltwin ah I think that's what happened to me. I don't recall what version of terraform I was using when I discovered the need to add a provider but it was an edge case in our configuration (cloudfront keys are only available in us-east-1) I found something that "just worked" and moved on. I've definitely been _running_ 0.11 for some time but if this hasn't been enforced then that would explain when I've not hit the problem before.

I just confirmed this fixed my problem. Closing the issue

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

darron picture darron  ยท  3Comments

c4milo picture c4milo  ยท  3Comments

rjinski picture rjinski  ยท  3Comments

ketzacoatl picture ketzacoatl  ยท  3Comments

larstobi picture larstobi  ยท  3Comments