Use old values with "null_resource"/ "triggers"

[franckbrouard]

Hello,

Current Terraform Version

0.11.13.

Attempted Solutions

I have a "null_resource" to manage access to a service "service". The resource is triggered on changing password.
When i launch terraform, it launch curl with the new password. How i can get old values to delete the good (old) password in the "destroy" part on my resource ?

resource "null_resource" "service_credential" {
  triggers {
    mailgun_password = "${var.service_password}",
   }
   provisioner "local-exec" {
    command = curl https://service/create/new/credentials/with/${var.service_password}
   }

   provisioner "local-exec" {
    when = "destroy"
     command = curl -X DELETE curl https://service/delete/old/credentials/with/${var.service_password}
   }
}

Thanks in advance for any tips...

Regards,
Franck

[apparentlymart]

Hi @franckbrouard!

From what you've described here, it seems like you are trying to implement a resource-like lifecycle (applying gradual changes to a long-lived object over time) using provisioners. Terraform doesn't support using provisioners in this way.

Within Terraform's current architecture, the best way to model your requirement there is to use a resource. You didn't mention what "service" is here, so I assume it's some internal system that doesn't have an existing Terraform provider. In that case, you could potentially implement a custom Terraform provider for that local system with a single resource credential, which might look something like this:

resource "yourservice_credential" "example" {
  password = "${var.service_password}"
}

If you mark the password attribute as being ForceNew: true in the resource type schema then the SDK itself will handle all of the lifecycle details for you here and you can just implement the Create and Delete methods to call the create and delete API endpoints you showed here, and then any change to the resource will cause the delete and create methods to be called.

At the moment there is no way to get a resource-like lifecycle without writing a provider in Go. The external provider currently gives a way to get a data-source-like lifecycle with an external program written in any language, and we've talked in the past about also offering a resource-like equivalent (see #8144) but need to complete some other work on the configuration language and the plugin SDK first so that the result can have fewer of the drawbacks users have seen with the external data source so far.