Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Terraform prompts to enter provider.aws.region" #1043

Closed
youssefNM opened this issue Jul 3, 2017 · 20 comments
Closed

"Terraform prompts to enter provider.aws.region" #1043

youssefNM opened this issue Jul 3, 2017 · 20 comments
Labels
bug Addresses a defect in current functionality. upstream-terraform Addresses functionality related to the Terraform core binary.

Comments

@youssefNM
Copy link

youssefNM commented Jul 3, 2017

Hi there,
it seems terraform version 0.9.6 is still affected by this bug hashicorp/terraform#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

hashicorp/terraform#10722
hashicorp/terraform#8680

@thearrow
Copy link

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:

@radeksimko radeksimko added bug Addresses a defect in current functionality. upstream-terraform Addresses functionality related to the Terraform core binary. labels Oct 23, 2017
@sdomagala
Copy link

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

@reedflinch
Copy link

Same issue with 0.11.1.

@jwinter
Copy link

jwinter commented Dec 21, 2017

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.

@edsonmarquezani
Copy link

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

@petewilcock
Copy link

petewilcock commented Jan 29, 2018

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.

@lapthorn
Copy link
Contributor

@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

@sjwl
Copy link

sjwl commented May 11, 2018

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"
  }
}

@russmac
Copy link

russmac commented Jul 19, 2018

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

@reedflinch
Copy link

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.

@dusansusic
Copy link
Contributor

You just need to read documentation more carefully :)

@pbnj
Copy link

pbnj commented Sep 14, 2018

@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.

@LeoncioXavier
Copy link

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?

@kgosietsileM
Copy link

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.

@edsonmarquezani
Copy link

edsonmarquezani commented Oct 3, 2019

@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.

@jsrice7391
Copy link

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

@mmell
Copy link
Contributor

mmell commented Mar 20, 2020

When using an alias, either

  1. ensure that every resource has a provider defined:
resource "aws_iam_role" "default" {
  provider = aws.usw2
}
  1. 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"
}

@Tensho
Copy link
Contributor

Tensho commented May 8, 2020

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
  ...
}

@bflad
Copy link
Contributor

bflad commented Jul 7, 2020

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.

@bflad bflad closed this as completed Jul 7, 2020
@ghost
Copy link

ghost commented Aug 6, 2020

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!

@ghost ghost locked and limited conversation to collaborators Aug 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. upstream-terraform Addresses functionality related to the Terraform core binary.
Projects
None yet
Development

No branches or pull requests