Terraform: Feature Request: AWS SSM run-command should be available as a provisioner

[james-masson]

Originally raised against the aws provider - https://github.com/terraform-providers/terraform-provider-aws/issues/8075 - but provisioners are a core terraform thing.

Current Terraform Version

Terraform v0.11.13

Use-cases

AWS SSM run-commands is not currently supported as a first-class concept in Terraform. In another issue, the reason given was that arbitrary timed commands are not really part of terraform's general workflow.

A provisioner would likely be the right place for it. As an example, I'd like to use ssm run-command as a destroy-time provisioner, to clean up state on a cluster node before destroying it.

Attempted Solutions

null_resource + scripting currently does what I want, but it's hacky.

Proposal

resource "aws_instance" "web" {
  # ...

  provisioner "aws_ssm_command" {
    command = "echo ${self.private_ip} >> private_ips.txt"
  }
}

References

https://github.com/terraform-providers/terraform-provider-aws/issues/2592
https://github.com/terraform-providers/terraform-provider-aws/issues/8075

[tcdev00]

This provisioner would be really useful.

[trevor403]

This would be very helpful, especially if it could wait for Status Checks to pass.

[BrianDehlinger]

This would be extraordinary useful!

[sergei-ivanov]

It looks like it may never happen, given that all 3rd-party provisioners have just been given a boot:
https://discuss.hashicorp.com/t/notice-terraform-to-begin-deprecation-of-vendor-tool-specific-provisioners-starting-in-terraform-0-13-4/13997

I quietly hoped that HashiCorp would create an API for provisioners in the same way that it has a provider API, so that provisioners could be unbundled from Terraform core. But I think there's no chance of that now.

[danieldreier]

@james-masson and @sergei-ivanov -

I'm closing this issue because we announced tool-specific (vendor or 3rd-party) provisioner deprecation in mid-September 2020. Additionally, we added a deprecation notice for tool-specific provisioners in 0.13.4. On a practical level this means we will no longer be reviewing or merging PRs for these built-in plugins.

The discuss post linked above explains this in more depth, but the basic reason we're making this change is that these vendor provisioners have been extremely challenging for us to maintain, and are a weak spot in the terraform user experience. People reach for them not realizing the bugs and UX limitations, and they're areas that are difficult for us to maintain because of the huge surface area of integrating with a bunch of different tools (Puppet, Chef, Salt, etc) that each require deep domain knowledge to do right. For example, testing each of these against all the versions of those tools, on multiple platforms, is prohibitive, and so we don't - but users have a reasonable expectation that everything in the Terraform Core codebase is well tested.

For the time being, the best option if you want to see this built, is to build a standalone provisioner and distribute it as a plugin binary, similar to how the ansible provisioner is distributed.

I'm aware of the limitations of this approach, but it's the less-bad option compared to coupling provisioner development to the Terraform Core release lifecycle. We believe the benefit to users of having provisioner development decoupled from core, exceeds the convenience of having these provisioners built in to core. We want to provide a better user experience in the future, and our hope here is that the ability to improve, fix and repair provisioners without us blocking their development, much like providers, will help make a strong case for what's next.

I think it’s also important to highlight that we have no plans to remove the generic provisioners or the pluggable functionality during Terraform's 1.0 lifecycle.

I appreciate your input here to improve Terraform, and am always happy to talk. Please feel free to reach out to me or Petros Kolyvas if you would like to talk more about this change.

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