Terraform: Read resource name in plugin

[jefferai]

The resource configuration example starts out with:

resource "aws_instance" "web" {

This is described as the type and the name, so that TYPE.NAME must be unique. It is reasonable to think of the name of the resource as being canonical.

However, there is currently no way to access that name from within a plugin. As a result, if I am doing something within my plugin that requires a name, I need to have the user type it again as a "name" parameter within the resource configuration.

I'd much prefer to be able to accept the name as-is, and only use a different name as the result of an optional configuration parameter rather than (as I have to do now) a required parameter with the same name as the resource itself.

[jen20]

:+1: on this - I spent some time looking for it too and eventually settled on duplicating the name.

[rogierlommers]

Same here, it would be great to have a resource "name" in one place.

[mitchellh]

We went back and forth on this a lot in the early early days of Terraform. I have also had a use for this though so I'm going to think on it but i'm leaning towards it.

[phinze]

This is still worth implementing. Unfortunately "name" collides with a bunch of attributes on existing resources, so we'll need to come up with a non-colliding reference for this. Perhaps tfname?

• self.tfname from within the config
• d.Get("tfname") or d.GetTFName() from within a plugin?

Removing thinking since we're all leaning towards doing it, just need to figure out the details.

[apparentlymart]

@phinze seems weird to me to model it as a resource attribute when this thing is part of the fundamental model of a resource.

Your proposed d.GetTFName() seems like the nicest option to me, though looking over the implementation it seems like it'll require a tweak to the schema helper's resource interface since currently the InstanceInfo (where the name comes from) isn't passed down into the resource-level Refresh, Diff and Apply methods.

I do have a more philosophical reservation about this idea, though: until now the name we're talking about has been local to a given Terraform module. If providers were to start using it in identifiers as a unique key then it would suddenly become effectively globally unique across an entire service/account. This troubles me because it seems like it would hurt the idea of an isolated namespace between child modules under a given root, as well as multiple separate Terraform configs all contributing to the same infrastructure.

I think exposing it under self within the config makes sense, since then it can be combined with other stuff to make it unique. But again it feels weird to have a synthetic attribute name. This seems like a further use-case for the meta namespace I proposed elsewhere when we were discussing unique ids, as a place to put metadata from Terraform core as opposed to data from the provider:

resource "foo_bar" "baz" {
    name = "${meta.self.config_name}-${var.environment}"
}

Of course, both this and your original idea of self.tfname are not significantly shorter than just literally typing "baz".

FWIW, in my world these names usually end up being embarassingly _un_-unique, because we split our infrastructure across many separate config files that all ultimately target the same AWS account. So our resources often have super-generic names like aws_instance.web_server and aws_db_instance.main, which are implied to be "the web server for the app whose config this is", etc.

[phinze]

seems weird to me to model it as a resource attribute when this thing is part of the fundamental model of a resource.

True. I see your point there and I agree.

I do have a more philosophical reservation about this idea...

Hmm this is a _very_ good point. I'll have to think a bit more about this. I think we should do everything we can to steer architectures in the direction of loosely coupled modules.

FWIW, in my world these names usually end up being embarrassingly un-unique

Same here. I often find myself using "mod" as a shorthand for "module local" in smaller modules.

Going to do some more thinking on this.

[charity]

Very eager to have this functionality as well. I am spinning up lots of aws_instance and autoscaling_groups, and would love to be able to automatically tag instance names with the resource_names that generated them.

[danyorr]

Just looked for this option and run into this issue.

[abourget]

I want to:

resource "aws_ebs_volume" "pv0003" {
  availability_zone = "us-west-2a"
  size = "20"
  tags {
    Name = "${var.deploymentName}-${self.resource_name}"
  }
}

Note the self.resource_name is just my imagination. Is there no way to do that today ?

[mattkenn4545]

bump

[apparentlymart]

Hi everyone! Sorry for the long silence here.

Exposing the module-local resource identifier as an interpolatable variable seems like the most robust path here, and I can see how it would be useful. However, we (the Terraform team) aren't likely to work on this in the forseeable future, so I'm going to close this as part of our effort to be more explicit about the status of these old, stale issues.

This doesn't mean that this will _never_ get done -- indeed, we would like to support something like this eventually -- but it requires adding some new concepts to Terraform (self-interpolatable resource metadata attributes) that we don't have the time to work on in the short term, and we'd rather be explicit about that than leave this issue open indefinitely.

Thanks for the great discussion here! It will all be useful should we start working on this in future.

[Ralf-Te]

Hello @apparentlymart,
I am totally fine with your approach to rather close issues than let them grow beards.
Nonetheless, I down-voted, because even if the topic could not be solved, it would be great to have at least a guideline/proposal, just something to be considered a good/ok practice.

Best regards

[apparentlymart]

Hi @Ralf-Te,

I appreciate your patience with our prioritization process, and I'm sorry we are unable to pursue this issue actively at this time.

We made the decision to close this one because it's the sort of issue where the design work for the feature is likely to be the hardest and most time-consuming part, with the eventual implementation being (hopefully!) more straightforward. We approach issues like this with care because Terraform features tend to interact in surprising ways.

The current state of this issue is that there is a path that seems promising (metadata interpolation variables, like ${meta.self.config_name}) but we have not yet been able to prototype such a thing and investigate how it would work within Terraform's existing architecture and whether it has any interactions we haven't yet thought of.

If someone in the community were interested in working on a design prototype -- that is, a proof-of-concept for discussion rather than a final solution -- we'd definitely be open to that. We always appreciate community members getting involved in the design of larger features but we're concious of the fact that this can be significantly more time-consuming than smaller features, provider enhancements, and bug PRs and so we want to be respectful of the fact that Terraform is a "side-project" for most contributors.

Thanks again to everyone who participated in the discussion here and shared their use-cases.

[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.