Terraform-provider-aws: "Terraform prompts to enter provider.aws.region"

Created on 3 Jul 2017  ·  20Comments  ·  Source: hashicorp/terraform-provider-aws

Hi there,
it seems terraform version 0.9.6 is still affected by this bug https://github.com/hashicorp/terraform/issues/8680
Sub modules seem to not pick the aws provider defined as a common module.

Terraform Version

0.9.6

Affected Resource(s)

  • provider aws

Terraform Configuration Files

Here is my configuration :

/modules/aws/main.tf
provider "aws" {
  allowed_account_ids = [XXXXXXXX]
  profile             = "test"
  region              = "us-east-1"
}

and in a sub module, i'm calling the aws module like this

module "aws_provider" {
  source = "../../../../modules/aws"
}

but it is still asking to enter the region.

Expected Behavior

The region defined in the aws provider module should be picked by the sub module, and never prompts for a new one.

Actual Behavior

provider.aws.region
  The region where AWS operations will take place. Examples
  are us-east-1, us-west-2, etc.

  Default: us-east-1
  Enter a value:

Steps to Reproduce

  1. terraform plan

References

https://github.com/hashicorp/terraform/issues/10722
https://github.com/hashicorp/terraform/issues/8680

bug upstream-terraform

Most helpful comment

This might seem silly, but I notice that when I specify any other attribute other than 'region' for a provider definition (in this example, an alias), it prompts me for the provider even if all of my resources are created using the alias.

Therefore my solution is:

provider "aws" {
  region = "us-east-1"
}

provider "aws" {
  region = "us-east-1"
  alias = "us_east"
}

A (somewhat redundant) 'default' definition, followed by a second definition with the attributes you want. This resolved the issue for me.

All 20 comments

Same issue here still with 0.10.7:

base.tf:

variable "region" {
  default = "us-east-1"
}

provider "aws" {
  region  = "${var.region}"
  version = "~> 1.1"
}

using in other module:

variable "region" {
  default = "us-east-1"
}

module "base" {
  source = "../base"
  region = "${var.region}"
}

terraform plan and terraform apply always prompt for region:

provider.aws.region
  The region where AWS operations will take place. Examples
  are us-east-1, us-west-2, etc.

  Default: us-east-1
  Enter a value:

For me it was issue that some resources were in the same directory as module initialization, therefore there was no region defined for them.

Something like

module "some_module" {

}

resource "some_resource" "name" {

}

Mind that terraform takes whole directory so you should check each file if there is no resource created.

Solution was simple for me, move everything to module, even if you create small resource because otherwise no provider is defined for it.

Hope it helps somebody, it's not answer to the issue per se, but maybe someone else missed that.

Cheers

Same issue with 0.11.1.

A workaround in the meantime is to use the environment variable AWS_DEFAULT_REGION, e.g. AWS_DEFAULT_REGION='us-east-1' terraform plan. This avoids the prompt, at least in v0.11.1.

Have been living with this for more than a year, or so. Everytime I use multiple providers I have to hit enter to apply.

This might seem silly, but I notice that when I specify any other attribute other than 'region' for a provider definition (in this example, an alias), it prompts me for the provider even if all of my resources are created using the alias.

Therefore my solution is:

provider "aws" {
  region = "us-east-1"
}

provider "aws" {
  region = "us-east-1"
  alias = "us_east"
}

A (somewhat redundant) 'default' definition, followed by a second definition with the attributes you want. This resolved the issue for me.

@petewilcock Your workaround works a treat, but I'm at a loss to the 'how' - I have exactly the same problem with:

Terraform v0.11.7                                                                                        │
+ provider.aws v1.15.0

It seems the best practice is to _not_ declare the provider in the child module, but rather keep all providers in the _root_ module, and pass the provider to the child module as a parameter either _implicitly_ or _explicitly_ as described here: https://www.terraform.io/docs/modules/usage.html#providers-within-modules

/modules/aws/main.tf

provider "aws" { #required proxy configuration block for now, that may go away in future
}

root module

provider "aws" {                                #default provider, for implicit declaration
  region              = "us-west-1"
}

provider "aws" {
  allowed_account_ids = [XXXXXXXX]
  profile             = "test"
  region              = "us-east-1"
  alias               = "use1"
}

module "aws_provider" {
  source = "../../../../modules/aws"
  providers = {                                 #explicit declaration
    aws             = "aws.use1"
  }
}

I've just run into this shortly after after enabling s3 backend & remote states:

terraform: 0.11.7
provider: terraform-provider-aws_v1.28.0_x4

I no longer have this issue across any of my Terraform modules. It may seem trivial, but this single nugget of information cleared up a LOT for me, so I'll share:

https://www.terraform.io/docs/modules/create.html

Modules in Terraform are folders with Terraform files. In fact, when you run terraform apply, the current working directory holding the Terraform files you're applying comprise what is called the root module. This itself is a valid module.

It took me an embarrassing amount of searching to definitively understand what a "root module" really is.

So, combining with @sjwl's advice, only declare providers where you run terraform apply.

You just need to read documentation more carefully :)

@reedflinch - same here. The wording root module threw me off thinking it refers to the parent module, not the current module. Thanks for the clarification.

Have been living with this for more than a year, or so. Everytime I use multiple providers I have to hit enter to apply.

Hey @edsonmarquezani did you find a way to get rid of this pain?

Have been living with this for more than a year, or so. Everytime I use multiple providers I have to hit enter to apply.

Lmfao sounds like you have been living with a disease.

@LeoncioXavier It's been some time since I stopped having to use multiple providers at once, but as far as I remember, I stopped declaring providers in modules, declaring only in the most "external" configuration (the one which really uses the module). I can't remember how I dealt with different regions in the same cloud, though, if I ever did. Declaring providers in different levels of configuration is wrong, anyway, this I'm sure.

Reporting this issue as still an issue. I was able to solve it and get by it by not using an alias.

terraform {
  required_version = ">= 0.12.0"
}
provider "aws" {
  alias                  = "cool_alias"
  version             = "~> 2.13"
  region              = "us-east-1"
}
resource "aws_vpc_peering_connection_accepter" "the_accepting_vpc" {}

The above configuration asks for the user to enter the region

terraform {
  required_version = ">= 0.12.0"
}

provider "aws" {
  version             = "~> 2.13"
  region              = "us-east-1"
}

Running terraform plan does not ask the user to enter the region

When using an alias, either

1) ensure that every resource has a provider defined:

resource "aws_iam_role" "default" {
  provider = aws.usw2
}

2) or create a non-aliased provider along with the aliased providers:

provider "aws" { # required to avoid typing a region
  region  = "us-west-2"
  version = "~> 2.54"
}

provider "aws" {
  alias   = "use1"
  region  = "us-east-1"
  version = "~> 2.54"
}

provider "aws" {
  alias   = "usw2"
  region  = "us-west-2"
  version = "~> 2.54"
}

I had exactly the case @mmell described. I specified a single provider with alias and forgot to set provider attribute in one of many resources. Terraform has a feature to infer provider by resource type prefix and of course it hasn't found region attribute in the implicit inferred provider configuration, that's why it asked for the region explicitly with prompt.

provider aws {
  alias   = "example"
  ...
}

resource aws_iam_policy x {
  provider = aws.example
  ...
}

resource aws_iam_policy y { # Terraform infers "was" provider by resource type prefix "aws_"
  # I forgot to put alias here
  ...
}

Hi folks 👋

Please note that as mentioned in the above two comments, if you are using multiple provider instances and only declaring provider configurations with alias values, then every resource or data source configuration _must_ include a provider configuration, otherwise Terraform will try to use an implicit "default" AWS Provider configuration, which is not available and where the error is coming from. This even includes things which do not require any region or credentials, such as the aws_arn data source. This requirement also applies across module boundaries. Please see the Modules documentation for more information about that particular aspect of working with Terraform configuration.

Given that the Terraform AWS Provider itself cannot give a different user experience for this problem (any changes would likely need to occur upstream in Terraform CLI to special handle this case) and that majority of these cases should be fixable via the two above documentation links, I'm going to close this since its not actionable here.

If you're looking for general assistance, please note that we use GitHub issues in this repository for tracking bugs and enhancements with the Terraform AWS Provider codebase rather than for questions. While we may be able to help with certain simple problems here it's generally better to use the community forums where there are far more people ready to help, whereas the GitHub issues here are generally monitored only by a few maintainers and dedicated community members interested in code development of the Terraform AWS Provider itself.

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

Was this page helpful?
0 / 5 - 0 ratings