Add stand-alone local-exec

[radeksimko]

The provisioner local-exec is currently tightly coupled to an existing resource (yeah, it's a "provisioner" so it makes sense).

It would be IMO nice to have a stand-alone resource "local-exec":

resource "local-exec" "create_web_in_aws" {
  command = "aws ec2 run-instances --image-id ami-123abcd | jq .Instances[0].InstanceId > web_instance_id.txt"
  unless = "aws ec2 describe-instances --instance-ids $(cat web_instance_id.txt)"
}

resource "local-exec" "create_web_in_gcloud" {
  command = "gcloud compute instances create myweb --image centos-6"
  unless = "gcloud compute instances describe myweb"
}

Instead of custom local files it could use the chosen TF state storage, so it's easily portable (e.g. capturing stdout from command and passing it to unless as stdin)?
The resource could have a different name to prevent confusions when looking at provisioners.

This would allow using providers or features that have not even been implemented into Terraform yet.

[phinze]

Oh hah I knew when I commented over on #1181 that there was something else recently talking about something similar, and here it is!

@radeksimko I think these two are conversations worth merging, but I think #1181 could be considered a superset solution to this. Do you agree? If so we can close this and move the conversation there, if you think there's merit for a "noop resource" as well as a top level "local-exec" resource we can continue that discussion here.

Let me know what you think! 💭

[radeksimko]

Hmm, I'm tempted to think these are two different use-cases we're discussing.

In fact I don't even want to call this a provisioner, the right name for this feature would be a "shell resource" (fully interchangeable with aws_autoscaling_group for example) from "system provider" (on the same level as aws or google). Except the API endpoint here is the OS shell.

It's basically something like Puppet's exec type which really in most cases turns out to be a helper for things you cannot do with the Puppet DSL (yet or never will do).

If you think I'm just misunderstanding #1181 then feel free to tell me :)

[phinze]

So the reason I think #1181 is a superset here, is that it's proposing a semantically neutral resource. So rather than adding a new resource type that's specific to local exec, we instead add a resource type that inherits all the generic behavior of resources, including provisioners and lifecycle management.

I suppose you could call the resource type "exec" or "provision_only" if you wanted, but the main idea is there is less need for new behavior like command or unless - most of it could be expressed in resource metaparameters and the existing resource mechanics:

resource "exec" "update-dns" {
  depends_on  = "aws_instance.web"
  provisioner "local-exec" {
    command = "./update-my-custom-dns ${aws_instance.web.public_dns}"
  } 
}

I'm still sort of concerned that implementing either one of these features could end up allowing people to shoot themselves in the foot too much.

But either way, does that help explain why this and #1181 feel like the same feature?

[radeksimko]

Ah, I think I understand now, so yes, closing this in favour of #1181

I'm still sort of concerned that implementing either one of these features could end up allowing people to shoot themselves in the foot too much.

Fair point, but at the same time it can also prevent any frustrations like "Terraform doesn't support X, so I cannot use it because it's crucial part of my infrastructure, even though I could use the DSL for 90% of the things I need".

I know that it's breaking the whole concept of nice and easy-to-use DSL, but sometimes hacks are needed and as long as people understand that these are actually hacks, then that's fine IMO.

[ghost]

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.