How to rewrite null_resource with local-exec provisioner when destroy (to prepare for deprecation after 0.12.8)

Terraform
1

Hello

I’m using null_resource and local-exec provisioners to publish message in Google Pubsub topic.
The usual provisioner is publishing a message to register the projet.
The “when destroy” provisioner is publishing a message to unregister the project.

Here is a sample code.

resource "null_resource" "project_mgmt" {
  provisioner "local-exec" {
    command = <<-EOC
gcloud pubsub topics publish projects/project_mgmt/topics/register --message '{"project":"${google_project.my_project.project_id}"}'
EOC
  }
  
  provisioner "local-exec" {
    when    = destroy
    command = <<-EOD
gcloud pubsub topics publish projects/project_mgmt/topics/unregister --message '{"project":"${google_project.my_project.project_id}"}'
EOD
  }

}

Could you help me to rewrite it ?

Here is the Warning with 0.12.18.
Warning: External references from destroy provisioners are deprecated

  on test.tf line 10, in resource "null_resource" "project_mgmt":
  10:     command = <<-EOD
  11: gcloud pubsub topics publish projects/project_mgmt/topics/unregister --message '{"project":"${var.gcp_project}"}'
  12: EOD

Destroy-time provisioners and their connection configurations may only
reference attributes of the related resource, via 'self', 'count.index', or
'each.key'.

References to other resources during the destroy phase can cause dependency
cycles and interact poorly with create_before_destroy.
2

Hi @lchastel,

When using null_resource, you can use the triggers map both to signal when the provisioners need to re-run (the usual purpose) and to retain values you can access via self during the destroy phase. For example:

resource "null_resource" "project_mgmt" {
  triggers = {
    project_id = google_project.my_project.project_id
  }

  provisioner "local-exec" {
    command = <<-EOC
gcloud pubsub topics publish projects/project_mgmt/topics/register --message '{"project":"${self.triggers.project_id}"}'
EOC
  }
  
  provisioner "local-exec" {
    when    = destroy
    command = <<-EOD
gcloud pubsub topics publish projects/project_mgmt/topics/unregister --message '{"project":"${self.triggers.project_id}"}'
EOD
  }
}

This makes the project id part of the stored state of the null_resource itself and thus avoids the dependency issues during the destroy phase that this deprecation warning is referring to.

5 Likes
3

Hello Martin

Thank you, it’s working.

Best regards
Laurent

4

@apparentlymart

What if project_id in triggers {} is sensitive value ? It will be visible in apply/plan, so how can I pass sensitive value destroy provisioner? Instead of making local_file resource and reference filepath as trigger, that would create another resource…
Its huge showstopper for me…
Thanks

2 Likes
5

How can we make this change if we have existing resources created by the null_resource? Adding the triggers makes terraform mark the resource for re-creation. In my case I can’t allow it to do that.

3 Likes
7

We have sensitive variables, usernames and passwords, present in our destroy time provisionsers. Moving them to the triggers block would save them to the state file and that is a show-stopper for us. Is there an alternative option available?

2 Likes
8

Another reason this is a problem is that adding the triggers, which causes the resource to be destroyed will run the very destroy-time provisioners that were using the external values.

The problem is they’re now referring to self.trigger.foo but the copy of the resource in the state doesn’t have that new trigger so it blows up with:

Missing map element: This map does not have an element with the key "foo"

So @apparentlymart, how can adding the new trigger ever fix this for existing resources? If I destroy the resource back on terraform 0.12 and add the new trigger then it’ll work the next time I need to destroy but I’m out of luck if I try to add the trigger in 0.13.