Closed percygrunwald closed 4 years ago
Hi @percygrunwald! Thanks for opening this issue.
What you've tried to do here is intentionally not supported in v0.13.0, as described in the v0.13 beta guide.
In later versions of Terraform we are intending to make it invalid to write provider
blocks anywhere except root modules, as has been the recommendation since Terraform 0.11. For now, this remains supported for modules that are not using count
and for_each
to retain compatibility with existing usage for now. However, it is technically infeasible to support modules in nested providers when count
and for_each
are present, so that will never be supported. Instead, we're planning to address it by changing the language features that associate provider configurations with resources so that provider configurations can be assigned more dynamically, which will follow in a later Terraform release.
Since there isn't any immediate action possible to fix this for now, I'm going to close this. We'll open other issues later for the provider-configuration-related language changes once there are more complete details to share.
Thanks again for opening this issue, and for the thorough reproduction steps you included.
@apparentlymart, thanks for the detailed response, I missed that advisory and we will update our modules in accordance with that. Sorry for the noise!
This deprecation of provider
blocks in anything other than the highest-level parent module will potentially cause a bit of pain for us, especially around keeping stuff DRY. Is there a thread to discuss the future implementation?
This makes impossible to use for_each for modules for multiregional cloud setups. For example, my module is one region infrastructure resources. I have different sets of AWS regions in which I need to deploy that infrastructure in every environment (workspace), so every environment setup is unique (no, I can't do anything with that). It makes non sense to have for_each for modules if I need to define AWS providers manually for each possible region for every environment in root module. And even if I define all providers, it's impossible to pass them to for_eached region module because provider could be addressed only by literal alias value and it's impossible to use "each.key" here. So, the feature I've been waiting and really wanting is useless for now for simplifying multiregional setups.
We're in a similar boat. We Terraform our AWS organization, with a subaccount
module for each subaccount in the organization, and that module sets up a provider scoped to the subaccount. We were waiting for module for_each to better organize the code for this (less repetition), but it seems that this isn't possible because the providers need to be defined at the root level, and there's no for_each
for providers. :-1:
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.
Terraform Version
Terraform Configuration Files
Expected Behavior
Modules should be nestable with each level able to define their own
provider
config, regardless of whether the child module is called withfor_each
or not.Actual Behavior
Modules are currently nestable with each level able to define their own
provider
config, unless the child module is called withfor_each
. This is unexpected and would create "special" modules that can't define their ownprovider
blocks and must be nested to be used (i.e. they cannot be used as top-level modules).Calling a child module that defines its own
provider
block from a parent module that also defines it's ownprovider
block results in this error only if the child is called withfor_each
from the parent:Steps to Reproduce
Please see code above. I can create code for a minimal PoC, but it is easy enough to reproduce this error for anyone experienced with terraform:
provider
blockprovider
block and calls the child module withoutfor_each
terraform init
andapply
on the parent module and everything worksfor_each
terraform init
andapply
on the parent module and receive an errorAdditional Context
Hi there, we have been waiting for the
0.13
so that we can tryfor_each
for a module, but are running into some unexpected behavior based on trying to abstract upon an existing module. Some background on the existing module and our use case:app_instance
module that launches 1 or moreaws_instance
s based on an inputmap
variable of the formhostname => instance_type
for_each
)prometheus_ha_pair
, which launches 1 or more pairs of instances based on the input variableha_pairs
, which is a map ofpair_id => instances
(see below for example)prometheus_ha_pair
module would create multiple pairs by calling theapp_instance
module in afor_each
loopWe tried to do this with the code below, but hit an error:
We have been able to resolve the problem by removing the
provider
block from theapp_instance
module, which then implicitly uses theprovider
config from the calling module. The problem with this is that now theapp_instance
module can no longer be used as a top-level module, since it has noprovider
configuration of its own. This also means we would have a module that is inconsistent with our other modules, which all define their ownprovider
blocks and which cause no problem with nesting inside other modules that define their ownprovider
block.We have tried keeping the
provider
blocks in place in both parent and child modules, then passing in theproviders
key to the child module from the parent to try to "overwrite" the child'sprovider
, but this just gave the same error.References
N/A