Terraform: Feature Request: Splat for all resources of a type

[philomory]

Current Terraform Version

Terraform v0.12.0-alpha4 (2c36829d3265661d8edbd5014de8090ea7e2a076)
+ provider.random v2.0.0-5-g612dff2-dev

Use-cases

I'd like to be able to use resource_type.*.id to get a list of the id of every resource of a type; currently, you can only do this for resources that have a count attribute (or eventually for_each, I guess). Sometimes, you have a bunch of resources you want to declare explicitly because they don't necessarily have very much in common, but you still want to refer to them all from another resource.

My explicit use-case is the third-party auth0 provider. I've got a bunch of auth0_client resources that all have their own custom configuration. Then, I've got an auth0_connection resource which represents our actual identity provider (an LDAP server). In creating the auth0_connection resource, I need to pass a list of auth0_client ids that that connection will be used for. And I'd _love_ to get that list of ids by simply writing auth0_client.*.client_id. But that's not possible.

Attempted Solutions

This didn't work:

resource "random_id" "foo" {       
  byte_length = 1                  
}                                  

resource "random_id" "bar" {       
  byte_length = 1                  
}                                  

output "example" {                 
  value = "${random_id.*.hex}"     
}                                  

I got this error:

$terraform validate

Error: Invalid reference

  on test.tf line 12, in output "example":
  12:   value = "${random_id.*.hex}"

A reference to a resource type must be followed by at least one attribute
access, specifying the resource name.

A similar attempt with random_id[*].hex also failed.

[Justin-W]

I have a need for the same use case as described above.

In addition, I'd like this 'resource type splat' feature to be usable in conjunction with the feature described in issue #9067 (and/or the upcoming for/for_each with optional filtering via an if qualifier) to enable me to create a single output variable whose value is a list of some or all of the resources (entire resources, not just IDs, or names) of a given type, without specifying or knowing the names or IDs of the included resources.

The need for this is based on my use of code generation tools to generate HCL dynamically. I want separate parts of my code generation to be able to generate HCL that will be combined with each other and applied as a single set of TF configuration, but also to have my separate code generation components to remain encapsulated and unaware of each other. But I'd like to have 1 component that generates output variables that collect all or some of the resources (and/or specific computed/exported attributes of them) into named output variables.

For example:

output "all_eips_list" {
  value = "${aws_eip.*}"
}

output "all_eip_public_ips_list" {
  value = "${aws_eip.*.public_ip}"
}

output "all_eip_public_to_private_ips_map" {
  # Result is a map from eip public IP to private IP address, such as:
  #  {"192.168.1.2" = "10.1.2.3", "192.168.1.5" = "10.2.3.4"}
  value = {
    for eip in aws_eip.*:
    eip.public_ip => eip.private_ip
  }
}

output "some_eip_public_to_private_ips_map" {
  # Result is a map from eip public IP to private IP address, such as:
  #  {"192.168.1.2" = "10.1.2.3", "192.168.1.5" = "10.2.3.4"}
  value = {
    for eip in aws_eip.*:
    eip.public_ip => eip.private_ip
    if eip.associate_with_private_ip_address
  }
}

Similar use cases exist for aws_lb.dns_name, aws_s3_bucket, and many other resources where the HCL configuration may contain a dynamic number of a specific type of resource (but not count-based repetition; each resource of the same type is explicitly declared separately, distinctly, and independently, as each resource of the same type has unique properties and configuration) and computed or exported attributes that aren't known until terraform apply or terraform refresh is executed.

[Justin-W]

A further (related but distinct) use case is that output variables similar to the examples above would (in many cases) be useful as 'reusable' HCL code, and could be included (without requiring any changes to the output variable HCL nor any configuration via input variables, etc.) in almost any arbitrary TF configuration that includes the referenced providers and resource types.

This would be useful to people that manage multiple TF configurations as a way of providing standardized (i.e. consistent across TF configurations, but with custom content and format determined by the output variables' reusable HCL definition) outputs.

This 'reusable outputs' use case applies equally well regardless of whether the separately managed TF configurations are manually generated or generated by code or by some other means.

[Justin-W]

Also, given that this change probably requires a change to HCL itself, it'd be great if this could be included in the initial v0.12 release. Is there still a chance of that?

[zygimantas]

One more use case:

I am creating N identical dynamodb tables in a module.
Module is called for each region (regional module).
In a root module, I need to create global dynamodb tables and I need regional table names.
It would be good, to return this output from a regional module:

output "table_names" {
  value = aws_dynamodb_table.*.name
}

[uutest74]

yes need this for output vars - different customized vms (windows and linux) created by module as different resources the same type!