Skip to content
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

Request: Custom Outputs from null_resource/local-exec #6830

Closed
qivers opened this issue May 23, 2016 · 11 comments
Closed

Request: Custom Outputs from null_resource/local-exec #6830

qivers opened this issue May 23, 2016 · 11 comments

Comments

@qivers
Copy link
Contributor

qivers commented May 23, 2016

Hi

I had a quick search but I couldn't find a feature request for this so apologies if it's a duplicate.

I was wondering if it would be possible to create custom outputs, from a null_resource, running a script in a local-exec?

Our current use case is that we are building custom AMIs. We would like to pass the AMI ID to our Terraform aws_instance and aws_launch_configuration resources without manually updating a variable in tfvars.

So the idea is, we'd have a null_resource with a local-exec which would pull in the latest AMI IDs using a script, and then we could assign the AMI ID outputted from that script to a terraform output;

resource "null_resource" "debian-ami" {
  provisioner "local-exec" {
    command = "python ./ami-finder.py -o debian"
  }
}

output "debiabn-ami-id" {
  value = "${null_resource.debian-ami.local-exec-output}"
}

This script would return the latest debian AMI ID which could then be ingested like any other module output;

ami_id = "${module.debiain-ami-finder.debian-ami-id}"

I realise this might be difficult but wondered if it was something worth considering?

Cheers.

@jen20
Copy link
Contributor

jen20 commented May 23, 2016

Hi @qivers! It's not possible to do this using null-resource, but the development branch of Terraform 0.7 (on master) now has data driven configuration, and a data source for finding AMIs is on the roadmap for that release!

@jen20 jen20 closed this as completed May 23, 2016
@alexraju91
Copy link

Hi, @jen20, I'm not able to see how v0.7.0 can fix this issue. This is required essentially for me as I'm using a script to get the private_ips of resources created by auto-scaling group. I need to pass this information to another TF module. So, I need to output this. Is there any way, I can acheive this?

@mrwilby
Copy link

mrwilby commented Aug 11, 2016

Could @jen20 @apparentlymart explain how to use the new "data sources" feature to run a local script and get the output as a terraform variable? TIA!

@apparentlymart
Copy link
Contributor

We don't (yet) have a data source for running a local command, but for the specific use-case given here (finding an existing AMI) we have aws_ami.

@alexraju91
Copy link

alexraju91 commented Aug 12, 2016

@apparentlymart Yup, like I thought. As far as I think, there is no direct way for this except some hack with null_resource trigger

@matti
Copy link

matti commented Feb 14, 2018

External data sources get run every time - if you just want to get output once, I made a module for this https://github.com/matti/terraform-shell-resource

@matti
Copy link

matti commented Mar 22, 2018

Update, now the module works also with remote state setups with an insane trick where I store the outputs in null_resource triggers and then ignore lifecycle changes for the triggers (!) https://github.com/matti/terraform-shell-resource/blob/master/main.tf#L58-L67

@matti
Copy link

matti commented Apr 16, 2018

Just revisited the solution mentioned above - managed to drop the requirement for external data source (ruby) now.

@mmack
Copy link

mmack commented Jul 2, 2018

Will this module find it's way into the core someday?

@matti
Copy link

matti commented Feb 9, 2020

https://github.com/matti/terraform-shell-resource has been updated so that it updates the outputs if command changes and does not run on every apply

@ghost
Copy link

ghost commented Feb 10, 2020

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.

@ghost ghost locked and limited conversation to collaborators Feb 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants