Hi guys.
I have question: Is there a solution/way dynamically collect the output from the same name of the all or selected modules to the list?
For example:
I have modules for creating AWS Security Groups: sg_name1, sg_name2, sg_name3... sg_nameX Each module have the same output: "name" = "sg nameX", "sg_id" = "sg idX".
Like :
output "sg_name_list" { value = "${split(",", module.*.name)}" }
output "sg_id_list" { value = "${split(",", module.*.sg_id)}" }
or
output "sg_name_list" { value = "${split(",", module.sg_*.name)}" }
output "sg_id_list" { value = "${split(",", module.sg_*.sg_id)}" }
Or can you recommend another way to automatically collect output from modules with the same output names?
Thanks
Hi @andrey-iliyov,
At this time Terraform doesn't support this sort of dynamic behavior, but rather requires each dependency to be spelled out explicitly. An important reason for this is that Terraform needs to be able to understand specifically which resources and other objects depend on others in order to properly determine the execution order.
With the current state of the configuration language, unfortunately writing out each item separately is the only approach that will work.
We are currently working on a revamp of the configuration language that will, eventually, allow treating resources and modules as a whole as objects within the configuration language. This doesn't entirely address your desire here, but it will at least allow writing configuration in a different way where the list of relevant modules needs to be listed out explicitly only once:
# DESIGN SKETCH: Not yet implemented
locals = {
security_group_modules = [
module.sg_foo,
module.sg_bar,
module.sg_baz,
]
}
output "sg_name_list" {
value = local.security_group_modules.*.name
}
output "sg_id_list" {
value = local.security_group_modules.*.id
}
Along with this, we do intend to support count
and similar features for module
blocks in future (as discussed in #953) but this depends on a sequence of other work around the configuration language and internal representations first, since currently our internal models do not allow for this sort of indexed module. At that point, assuming that the set of security group module instances are similar enough to make sense, something like this could be done:
# DESIGN SKETCH: Not yet implemented
module "security_groups" {
source = "./security-group"
count = length(var.security_groups)
name = var.security_groups[count.index].name
# etc, etc
}
I'm sorry I don't have anything more immediate to report, but I can confirm that this configuration language revamp is in progress and will solidify over the next few releases as we gradually redesign different parts of Terraform's internals around it.
Most helpful comment
Hi @andrey-iliyov,
At this time Terraform doesn't support this sort of dynamic behavior, but rather requires each dependency to be spelled out explicitly. An important reason for this is that Terraform needs to be able to understand specifically which resources and other objects depend on others in order to properly determine the execution order.
With the current state of the configuration language, unfortunately writing out each item separately is the only approach that will work.
We are currently working on a revamp of the configuration language that will, eventually, allow treating resources and modules as a whole as objects within the configuration language. This doesn't entirely address your desire here, but it will at least allow writing configuration in a different way where the list of relevant modules needs to be listed out explicitly only once:
Along with this, we do intend to support
count
and similar features formodule
blocks in future (as discussed in #953) but this depends on a sequence of other work around the configuration language and internal representations first, since currently our internal models do not allow for this sort of indexed module. At that point, assuming that the set of security group module instances are similar enough to make sense, something like this could be done:I'm sorry I don't have anything more immediate to report, but I can confirm that this configuration language revamp is in progress and will solidify over the next few releases as we gradually redesign different parts of Terraform's internals around it.