Terraform: "count" for provider configurations

[pmoust]

More of a feature request.

Terraform Version

Terraform v0.7.5

Affected Resource(s)

• provider.aws
  

  Terraform Configuration Files

provider "aws" {
  profile = "prod6"
  count   = "${length(var.aws_regions)}"
  alias   = "${element(var.aws_regions, count.index)}"
  region  = "${element(var.aws_regions, count.index)}"
}

variable "aws_regions" {
  default = [
    "us-east-1",
    "us-west-1",
    "us-west-2",
    "eu-west-1",
    "ap-northeast-1",
    "ap-southeast-1",
    "ap-southeast-2",
    "sa-east-1",
  ]
}

resource "aws_s3_bucket" "test" {
  bucket   = "just-a-random-bucket-name"
  acl      = "public-read"
  provider = "ap-northeast-1"

  versioning {
    enabled = true
  }

  tags {
    Name        = "test"
    environment = "prod"
    managed-by  = "terraform"
    owner       = "cloud"
  }
}

Debug Output

2016/10/19 13:38:59 [WARN] Invalid log level: "1". Defaulting to level: TRACE. Valid levels are: [TRACE DEBUG INFO WARN ERROR]
2016/10/19 13:38:59 [INFO] Terraform version: 0.7.5
2016/10/19 13:38:59 [INFO] CLI args: []string{"/usr/local/Cellar/terraform/0.7.5/bin/terraform", "plan", "-out=/tmp/plan"}
2016/10/19 13:38:59 [DEBUG] Detected home directory from env var: /Users/pmoust
2016/10/19 13:38:59 [DEBUG] Detected home directory from env var: /Users/pmoust
2016/10/19 13:38:59 [DEBUG] Attempting to open CLI config file: /Users/pmoust/.terraformrc
2016/10/19 13:38:59 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2016/10/19 13:38:59 [DEBUG] Detected home directory from env var: /Users/pmoust
2016/10/19 13:38:59 [TRACE] Preserving existing state lineage "da1bb4f6-a316-4223-a229-2c3bcb8c673c"
2016/10/19 13:38:59 [TRACE] Preserving existing state lineage "da1bb4f6-a316-4223-a229-2c3bcb8c673c"
2016/10/19 13:38:59 [DEBUG] plugin: waiting for all plugin processes to complete...
module root: 1 error(s) occurred:

* aws_s3_bucket.test: resource depends on non-configured provider 'ap-northeast-1'

Expected Behavior

I would love to have providers defined as the above example HCL. Docs implicitly suggest that one needs to repeat the provider configuration.
Expected behavior would be to create a bucket in 'ap-northeast-1'

Actual Behavior

root module error.

Steps to Reproduce

1. terraform apply

[nyetsche]

Looks like there's an issue covering this as well - https://github.com/hashicorp/terraform/issues/11578

[automaticgiant]

i can interpolate normal variables into the provider blocks but not local variables. this would let me set up a map so i can use the right profile for the particular environment.

as a workaround, i am doing local computation in root module and passing into the module who has its own provider because i can't set up the provider like that and pass it in.

actually no, that's not working either, even with refresh=false.
:(

[bchallenor]

I would also like count support for providers, in order to create a resource in multiple regions.

Note that there is a feature request to add count support for modules, which would provide a different way to achieve the same result.

[hryamzik]

That also requires some support for resources

resource "some_aws_resource" "test" {
  provider   = "aws.${element(var.aws_regions, count.index)}"
  count      = "${length(var.aws_regions)}"
}

Currently fails with configuration for aws.${element(var.enclaves, count.index)} is not present; a provider configuration block is required for all operations

Relates to #16967

[alexharv074]

Is there any known workaround here?

[cvemula1]

sam issue I'm facing

[nanoz]

Would that be technically possible to implement this in HCL2 ?

[Misosooup]

Need this too. Is this being addressed?

[nikolay]

Having for_each now for modules in v0.13 makes the static provider assignment erase all the benefits of for_each. Why not having for_each for providers with dynamic aliases as well?

[apparentlymart]

Hi @pmoust, and everyone else! Thanks for proposing this and for the ongoing discussion.

After some consideration of the various parts, I think this proposal has the same underlying use-case as #24476. Although that one is newer, there is lots of discussion there about different use-cases and proposals, and so I'm going to close this one to consolidate into that one. I'd also like to draw your attention to the comment I left there about the state of things right now and the low likelihood of addressing these use-cases in the very near future.

Thanks again for opening this, and I'm sorry for being the bearer of some sub-awesome news today.

[tomasbackman]

Good detailed answer/comment @apparentlymart. Even though it is not the answer we hoped for it is understandable, thank you

[hashibot[bot]]

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.