I am trying to update to Terraform 0.11, but running terraform plan is producing a bunch of errors:
Error: module.mongodb_server.provider.aws: "region": required field is not set
Error: module.rocketchat_web.provider.aws: "region": required field is not set
Error: module.stack.module.consul.module.server_asg.provider.aws: "region": required field is not set
Error: module.stack.module.vpc.module.jumphost.provider.aws: "region": required field is not set
Error: module.stack.module.vpc.provider.aws: "region": required field is not set
I'm trying to come up with some code to reproduce this, but I haven't been able to do so just yet. The command that I am running is terraform plan -var-file terraform.tfvars -var-file ../terraform.tfvars -input=false templates
Ah okay, the problem is that we are specifying a version requirement for the aws provider in our modules, like so:
provider "aws" {
version = ">= 1.0.0"
}
This means that the root aws provider is not inherited from the parent configuration... is this expected?
Hi @joshuaspence! Sorry for this new behavior, and thanks for reporting it.
It looks like this is a poor interaction between two different features: ability to constrain provider versions on the one hand and the new explicit provider passing behavior on the other. The syntax you used here is making Terraform expect a provider configuration to be passed in by the calling module using the new providers argument.
Constraining a provider version without also configuring the provider is, to be honest, not a situation we'd considered... often providers are configured only in the root module and then passed down, but I can definitely see the idea here of saying "this module contains resources that depend on features only available in 1.0.0 or newer".
We'll have to think about how to make it easier to distinguish these scenarios here. Unfortunately the provider block is now serving a number of different slightly-conflicting purposes. I'll chat with @jbardin about this tomorrow and see what path makes sense here.
In the mean time, I think it should be possible (though indeed not convenient) to work around this by explicitly passing the provider configuration from parent to child using the new syntax:
module "foo" {
# ...
providers = {
"aws" = "aws"
}
}
The above should cause Terraform to treat the empty (apart from version) provider block in the child as a "proxy" for the provider being passed in by the parent, thus getting back the inheritance behavior you were seeing before, at the expense of some additional boilerplate in the config to override the new default behavior.
Thanks. I've just removed the version requirements for now.
Sorry about the confusion here.
This _is_ working as designed, but does conflict with the wording in the upgrade guide.
The upgrade guide states _"Only unaliased provider configurations can be automatically inherited ..."_, where the implementation is _"Only implicit provider configurations can be automatically inherited ..."_. This behavior allows a module to be able to declare a provider with an empty configuration without it being unconditionally overridden by a parent module.
My use case is to ensure that a tf module is bound to a particular region - because (for example) AMIs are region specific (and instance types also often are). Is there a way to ensure a module is not accidentally bound to the wrong region in TF 0.11?
The solution to this problem of declaring a required version without creating a provider configuration was written up over in #16835 and has now been implemented. This change will be included in the forthcoming v0.12.0 release.
You can read the full details over there, but the summary is that we now support a block within the terraform block for setting version requirements alone, without creating a new provider configuration:
terraform {
required_version = "~> 0.11"
required_providers {
aws = "~> 1.1"
consul = "~> 1.0"
}
}
Since this is addressed in the master branch, I'm going to close this out.
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.