-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Again need a way to refer to computed values within a resource #23966
Comments
Is there any update on this issue? It's been open for a year and it would be really helpful |
Adding weight to this use case, I have pretty much the same issue when trying to return ec2 instance inside a root block stanza: resource "aws_instance" "ec2" { We have automated processes that check for instance ID tags on volumes and this constantly trips our enterprise compliance monitors. |
One more use case is when converting |
I have same issue/desire. I was wondering if a possible workaround is to create an input variable or local to hold the name of the resource, then refer to the variable in the resource definition as well as inside it, but this is not possible for a variety of reasons:
|
Having found myself here via a long and careful search, I'd like to note for the record that this is a duplicate of:
So for the benefit of the next person to go on this particular snipe hunt: no, you can't do this. No, it is not being worked on by hashicorp. No, it is probably not worth your time to try to implement it yourself in a PR (although if you do please tag me in it as an interested party). Yes, the only workaround is to create a variable or a local that contains the resource name and use that in all of the places where you'd want to refer to it. |
This will be very useful for applying DRY principle also... We are creating each resource block with an explicit naming then have to create same pattern in tag blocks' name field when using common tags approach. Any mistake on these parts doesn't cause any build failure but causes wrong/miss results in cost explorer calculation etc.. If there are automation solutions based on tags then it is also causing problems.. |
I'm hopping the Here is my use case:
Next we need to enable secret rotation every 10 days.
Code looks great but it won't work because |
I don't think Normally given the ability of the resource to have a The other option is to use a secondary resource like |
Wiz locks their documentation behind an account system, it's not reachable.
This is an absolutely execrable API/resource design, because this means you have to manually re-run your deployment scripts. You don't want to do that, you want to run them once and then have whatever system is holding those keys manage them for you (if possible). |
Ye, 100% agree there, if this was Open Source I would add As far as the So the workaround to the limitation to the self is to use |
@Clockwork-Muse yes as long as you don't have CRON available yes it will need manual intervention
translation: Pass the hot potato... |
Current Terraform Version
Use-cases
We need a way to refer to computed values in a resource within a resource. In this case, we are using the aws_instance resource. Our requirement is that we need to create a tag that is assigned to volumes used and defined with with in the resource which contains the instance id.
There are volume tags available where the tag can be created but there is no way to refer to the id of the instance to set as a value for the tag.
Attempted Solutions
volume_tags = {
Name = "${var.baseName}-slave-east-1-${count.index + 1}"
t_instance_id = self.id
}
Error: Invalid "self" reference
on jenkins.tf line 266, in resource "aws_instance" "jenkins_slave_east":
266: t_instance_id = self.id
Proposal
Allow the values of the resource to be accessed using a construct like self.id. Self is a value that is used elsewhere with in HCL but is not valid in this case.
resource "type" "name" {
...
volume_tags = {
Name = "${var.baseName}-slave-east-1-${count.index + 1}"
t_instance_id = self.id
}
}
References
The text was updated successfully, but these errors were encountered: