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
❯ terraform version
Terraform v0.14.3
+ provider registry.terraform.io/terraform-provider-openstack/openstack v1.35.0
+ provider registry.terraform.io/terraform-providers/ignition v1.2.1
Your version of Terraform is out of date! The latest version
is 0.14.7. You can update by downloading from https://www.terraform.io/downloads.html
Use-cases
We are setting up different environments with Terraform and while we would like to continue iterating on our Terraform related setup, we can't role out everything to already setup environments to update them constantly. This is why we decided to version (git tag) our terraform modules and currently install them like so:
I can provide multiple entry points (as in .tf files) depending on when infrastructure was created. This works, but I can't really DRY. And end up repeating boilerplate. It's doable of course, but being allowed to use a variable in source would make this part a lot shorter and more maintainable.
My current solution revolves around either using sub directories where I duplicate the boilerplate and symlink parts of it "in" to keep it lean. I've been also considering another Makefile to chain it all together. But that ends up being complicated as well at some point.
Proposal
I'd like to be able to inject the source via a variable, or a variable into the source.
# I can provide a default, but override via .tfvars variable"module_version" {
default ="1.0.0"
}
module"foobar" {
source ="git@github.com:organisation/repository//foobar-module?ref=${var.module_version}"`
}
# as an alternative, the complete URI to the modulemodule"foobar" {
source =var.module_source`
}
Wanted to add how much I already love what modules has become. It's come along way from when I first started toying with this and supports us on an almost daily basis in our work.
The text was updated successfully, but these errors were encountered:
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.
hashicorp
locked as resolved and limited conversation to collaborators
Apr 2, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current Terraform Version
Use-cases
We are setting up different environments with Terraform and while we would like to continue iterating on our Terraform related setup, we can't role out everything to already setup environments to update them constantly. This is why we decided to version (
git tag
) our terraform modules and currently install them like so:Attempted Solutions
I can provide multiple entry points (as in
.tf
files) depending on when infrastructure was created. This works, but I can't really DRY. And end up repeating boilerplate. It's doable of course, but being allowed to use a variable insource
would make this part a lot shorter and more maintainable.My current solution revolves around either using sub directories where I duplicate the boilerplate and symlink parts of it "in" to keep it lean. I've been also considering another
Makefile
to chain it all together. But that ends up being complicated as well at some point.Proposal
I'd like to be able to inject the source via a variable, or a variable into the source.
References
Wanted to add how much I already love what modules has become. It's come along way from when I first started toying with this and supports us on an almost daily basis in our work.
The text was updated successfully, but these errors were encountered: