Terraform: Retrieve any resource attribute in terraform_remote_state

[mcanevet]

Hello,

Currently we have to use outputs to pass values from one project to another using the terraform_remote_state datasource while it should have the whole remote state, and hence should be able to access to any resource attribute in the remote state.

It would be great if we could write something like that:

data "terraform_remote_state" "vpc" {
    backend = "atlas"
    config {
        name = "hashicorp/vpc-prod"
    }
}

resource "aws_instance" "foo" {
    # ...
    subnet_id = "${data.terraform_remote_state.vpc.aws_subnet.subnet.id}"
}

If I name my output resource aws_subnet.subnet.id if works, but I still have to declare an output resource, and moreover, I'm not sure it's a good idea on the long term to have dots in resource names...

[mattkenn4545]

+1 on this. Suggestion might be to handle external resources in a similar way to exported resources in Puppet. Ie the the data from collections (ala terraform_remote_state) result in the resource being in the catalog (state in terraform) but read only.

This could allow for a 'resource_like' resource type that says make a resource in the current state that looks like this remote one. I'm sure there would be dragons but something like

resource "like_resource" "ec2" {
source = "terraform_remote_state.main.ec2"

ami = "blah"
...
}

would resource in aws_instance.ec2 in the current state based on the resource terraform_remote_state.main.ec2

[halfpastjohn]

+1 for this as well. It is redundant to expose the state file and then have to explicitly expose the resources in the state file.

If not the above suggestions, it would be nice to be able to expose, for instance, a subnets.tf file instead of having to create 50-something output resources for every single subnet.

[apparentlymart]

Hi everyone! Thanks for the great discussion here.

It is intentional that only the outputs are exposed here, because the exact resources in use and their names are an implementation detail of the remote configuration. The purpose of using output is to create a well-defined interface that is separate from the current implementation.

You're right that it's rather strange that Terraform retrieves the entire state just to retrieve the outputs, and indeed that presents some other interesting issues around including sensitive values in the state and making access controls difficult. It is likely that in future there will be a new mechanism to publish _just_ the outputs in order to address these concerns.

The other part of this is, I think, the desire to be able to return structured data in an output. Currently only strings, lists and maps can be returned as outputs, making it annoying to pass back all or a subset of the attributes of a resource. This is something we intend to address in future via some changes to how Terraform deals with types, possibly (though not necessarily, depending on any as-yet-unknown implications) including the ability to return the entire structure of a resource as an output. Indeed at that point we will probably break the ability to use periods directly in output names, so I would suggest avoiding that even though it is currently permitted.

Since this was an intentional constraint, I'm going to close this. However, I understand that the current situation is not convenient -- I've written my fair share of boilerplate output blocks copying almost every attribute from a resource -- so we are looking forward to addressing this annoyance in a way that doesn't break the abstraction of a module.

[halfpastjohn]

Might I suggest that "output" be an attribute for resources/variables? Such as:

variable "region" { description = "The AWS region to launch into" default = "ap-northeast-1" output = "region" }

Basically embed the output resource into the actual resource.

[timwsuqld]

@apparentlymart Are there any updates on how this is being implemented for the future?

[hashibot[bot]]

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.