You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I apologize if this has already been requested, but I haven't been able to find a relevant issue
Current Terraform Version
Terraform v1.1.3
on linux_amd64
Use-cases
I sometimes have a module that may or may not need additional provider aliases for a provider. And there isn't a good way to make an alias in configuration_aliases in the
For example, suppose I have a module for creating an s3 bucket and associated resources, and I want to have an option to have that bucket replicated to one or more regions and include the replicated buckets in the module. In order to do this I need a configuration alias for the aws provider for each region (since the provider needs to have the correct region specified).
Attempted Solutions
In the case that you just have an optional provider there are a couple of approaches:
Make two versions of the module, one that doesn't require an additional provider alias, and one that does. This requires keeping the code in sync, has a risk that one will be updated and not the other leading to bugs. And blows up in complexity if the module itself is used in another module that itself may or may not need the second provider config.
Make the alias required, and in the case it isn't needed the caller passes in the same provider for both. This is awkward, somewhat complicated, and error-prone.
If you want/need to accept a variable number of provider aliases, there isn't really much you can do, besides maybe using some sort of terraform code generator. Or possibly use on of the above approaches, but create N copies for approach 1, or require N aliases in approach 2, where N is the maximum number of aliases you want to accept.
Proposal
Maybe add a configuration_alias_lists option to the required_providers section, and a for_each_provider meta-argument for resources and modules, that would look something like:
Thanks for filing the issue. The current mechanism for provider resolution needs to be static, because we need to determine exactly which providers are required before evaluating fully evaluating the configuration. This splits the problem into two parts, first is the ability to create provider configuration instances dynamically, which is tracked in #19932. The second is the ability to pass multiple provider configurations into modules expanded with for_each, and that is being tracked in #25244.
The implementation details aren't really relevant here, but we do need to accommodate the fact that the names must be statically known, while the actual configuration instances are set at runtime. Thanks for the additional feedback, and we will continue to track the feature in #25244.
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.
I apologize if this has already been requested, but I haven't been able to find a relevant issue
Current Terraform Version
Use-cases
I sometimes have a module that may or may not need additional provider aliases for a provider. And there isn't a good way to make an alias in
configuration_aliases
in theFor example, suppose I have a module for creating an s3 bucket and associated resources, and I want to have an option to have that bucket replicated to one or more regions and include the replicated buckets in the module. In order to do this I need a configuration alias for the aws provider for each region (since the provider needs to have the correct region specified).
Attempted Solutions
In the case that you just have an optional provider there are a couple of approaches:
If you want/need to accept a variable number of provider aliases, there isn't really much you can do, besides maybe using some sort of terraform code generator. Or possibly use on of the above approaches, but create N copies for approach 1, or require N aliases in approach 2, where N is the maximum number of aliases you want to accept.
Proposal
Maybe add a
configuration_alias_lists
option to the required_providers section, and afor_each_provider
meta-argument for resources and modules, that would look something like:References
Somewhat related to #24188 since the provider block is a meta-argument.
The text was updated successfully, but these errors were encountered: