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've got a terraform stack which needs to create AWS secrets in multiple different places: I create some RDS DB instances and for each instance, I create a secret which has the login credentials for that DB; and I also need to create secrets for completely unrelated API login information elsewhere in the terraform code.
I'm using a secrets module I've written and stored in github to do this. However, because I'm calling this module in multiple places, keeping the versions correct is very brittle and wet. As I understand it, the point of modules is to do what functions do in programming languages: abstract away common tasks to avoid code duplication. But because I have to hard code the version and git repo URL in each of these module calls, I'm bound to get out of sync somewhere. I think interpolation would greatly help make this code maintainable.
Proposal
I would like to have a single yaml file with all of my module configuration info in it:
Without the ability to do this, it's extremely difficult to ensure that all module calls are using the correct versions. On top of this, it would just be much easier to have all module version info in one place, similar to a requirements.txt file in python, rather than have to dig through the code to find out what versions are being used.
References
This issue was discussed in #1439 and #18063, but both of those are marked as issues/bugs and have been closed as won't fix. I couldn't find a feature request on this issue, so I'm opening one here.
The text was updated successfully, but these errors were encountered:
ssanpietro-gr
changed the title
Allow interpolations in module source parameter
Feature request: Allow interpolations in module source parameter
Oct 10, 2020
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.
ghost
locked as resolved and limited conversation to collaborators
Nov 20, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current Terraform Version
Use cases
I've got a terraform stack which needs to create AWS secrets in multiple different places: I create some RDS DB instances and for each instance, I create a secret which has the login credentials for that DB; and I also need to create secrets for completely unrelated API login information elsewhere in the terraform code.
I'm using a secrets module I've written and stored in github to do this. However, because I'm calling this module in multiple places, keeping the versions correct is very brittle and wet. As I understand it, the point of modules is to do what functions do in programming languages: abstract away common tasks to avoid code duplication. But because I have to hard code the version and git repo URL in each of these module calls, I'm bound to get out of sync somewhere. I think interpolation would greatly help make this code maintainable.
Proposal
I would like to have a single yaml file with all of my module configuration info in it:
modules.yaml
:And then reference these version configurations wherever I call a module:
locals.tf
:main.tf
:Without the ability to do this, it's extremely difficult to ensure that all module calls are using the correct versions. On top of this, it would just be much easier to have all module version info in one place, similar to a
requirements.txt
file in python, rather than have to dig through the code to find out what versions are being used.References
This issue was discussed in #1439 and #18063, but both of those are marked as issues/bugs and have been closed as won't fix. I couldn't find a feature request on this issue, so I'm opening one here.
The text was updated successfully, but these errors were encountered: