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

Dynamic or optional provider aliases in module #30461

Closed
tmccombs opened this issue Feb 2, 2022 · 2 comments
Closed

Dynamic or optional provider aliases in module #30461

tmccombs opened this issue Feb 2, 2022 · 2 comments
Labels
enhancement new new issue not yet triaged

Comments

@tmccombs
Copy link
Contributor

tmccombs commented Feb 2, 2022

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:

  1. 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.
  2. 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:

terraform {
  required_providers {    
      aws = {
          source  = "hashicorp/aws" 
          version = ">= 2.7.0"
          configuration_alias_lists = [ aws.alternates ]
      }
   }
}

resource aws_s3_bucket {
  for_each_provider = aws.alternates
  
  # ...
}

References

Somewhat related to #24188 since the provider block is a meta-argument.

@tmccombs tmccombs added enhancement new new issue not yet triaged labels Feb 2, 2022
@jbardin
Copy link
Member

jbardin commented Feb 2, 2022

Hi @tmccombs,

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.

@jbardin jbardin closed this as completed Feb 2, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Mar 5, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement new new issue not yet triaged
Projects
None yet
Development

No branches or pull requests

2 participants