null_resource trigger with interpolated value used as an output fails

[tomelliff]

I'm finally getting around to moving from 0.10.8 to 0.11+ but am having issues with outputting the value of a trigger that is interpolated from another resource. I have an aws_ecs_task_definition that I pass to an aws_ecs_service resource and then I use a null resource with a local exec provisioner to wait for the deployment to finish using the AWS CLI (I need this until hashicorp/terraform-provider-aws#3485 is merged) so I know that the deployment is complete.

This is all wrapped in a shared module that we use for all of our ECS services but we also have a web facing service that has Cloudfront in front of it where we invalidate the cache after the deployment so the ECS service module needs to output something from the null resource so that I can have Terraform wait for the deploy to be complete before then running the Cloudfront cache invalidation.

It works fine as is (and has done for months of 0.10.8 usage now) but apparently it is failing the output interpolation check introduced in 0.10.8 (that quietly failed previously) and enforced in 0.11+. I'm not too sure why it seems to fail with triggers but specifically only interpolated ones and not statically defined trigger values (such as triggers { foo = "bar" }}. At first I thought Terraform was complaining because the null resource may not execute if there's no change to any of the triggers and so there's no guarantee that the null resource would be executed but I think that should also apply to statically defined trigger values. Am I misunderstanding something about the graph Terraform is building here or is this a bug one way or the other?

I'm considering simply setting TF_WARN_OUTPUT_ERRORS=1 in helper scripts for now and hoping that the above linked PR gets merged and released before 0.12 because I think this is the only case I need this but I'm curious as to the cause of this error before I suppress it.

Terraform Version

Terraform v0.11.4
+ provider.aws v1.11.0
+ provider.null v1.0.0

Terraform Configuration Files

task-def.json:

[
  {
    "name": "first",
    "image": "service-first",
    "cpu": 10,
    "memory": 512,
    "essential": true,
    "portMappings": [
      {
        "containerPort": 80,
        "hostPort": 80
      }
    ]
  },
  {
    "name": "second",
    "image": "service-second",
    "cpu": 10,
    "memory": 256,
    "essential": true,
    "portMappings": [
      {
        "containerPort": 443,
        "hostPort": 443
      }
    ]
  }
]

This plans fine:

main.tf

resource "aws_ecs_task_definition" "task_def" {
  family                = "foo"
  container_definitions = "${file("task-def.json")}"
}

resource "aws_ecs_service" "service" {
  name            = "foo"
  cluster         = "dev"
  task_definition = "${aws_ecs_task_definition.task_def.arn}"
  desired_count   = "1"
  iam_role        = "ecsServiceRole"
}

resource "null_resource" "wait_for_service_deploy" {
  triggers {
    # task_definition = "${aws_ecs_service.service.task_definition}"
    static_trigger = "foo"
  }

  provisioner "local-exec" {
    command = "echo foo"
  }
}

# output "null_resource_task_definition" {
#   value = "${null_resource.wait_for_service_deploy.triggers.task_definition}"
# }

output "null_resource_static_trigger" {
  value = "${null_resource.wait_for_service_deploy.triggers.static_trigger}"
}

Uncommenting the task_definition trigger and the null_resource_task_definition output and planning causes it to error:

* output.null_resource_task_definition: Resource 'null_resource.wait_for_service_deploy' does not have attribute 'triggers.task_definition' for variable 'null_resource.wait_for_service_deploy.triggers.task_definition'

Running with TF_WARN_OUTPUT_ERRORS=1 terraform plan it plans okay but the above error message is written to the log.

Checking 0.10.8 it also appears to be quietly erroring there as well (is there a way I can make warnings like this more visible when running much like the deprecation notices in resources? I've been sitting on this issue for a while apparently but didn't notice it in logs because I don't look at them unless something is broken) so it's not something new.

Expected Behavior

It should plan/apply fine

Actual Behavior

It fails

Steps to Reproduce

terraform init
terraform plan

[jbardin]

Hi @tomelliff,

Thanks for filing this! I've been able to reproduce the issue with triggers here, and will look into it.

If you need to work around the problem at the moment, you can set TF_WARN_OUTPUT_ERRORS=1 to bypass the output errors during plan.

[hargut]

I've also run into that issue, and it also seems to affect data null_data inputs.
It can as well be circumvented by setting TF_WARN_OUTPUT_ERRORS=1.

[bendrucker]

I've also run into this issue and described my setup in detail in poseidon/typhoon#224.

I noticed that it's not the presence of interpolations that causes this error, but specifically interpolations that are asynchronous and happen in the apply phase instead of during a plan.

In the original example ${aws_ecs_service.service.task_definition} meets that condition. Passing that value as an input to a module and then using that variable as a trigger also causes the same error. But triggers that can be resolved at plan time are available as exported attributes.

[johansnow]

Isn't this particular case because the trigger is either static (works) or referencing a resource with count without actually referencing a particular element?
What would happen if the commented our trigger in the original post
# task_definition = "${aws_ecs_service.service.task_definition}"

was changed into
task_definition = "${aws_ecs_service.service.*.task_definition}"

[YusDyr]

Got the same behavior

$ terraform -v
Terraform v0.11.8
+ provider.google v1.16.2
+ provider.null v1.0.0
+ provider.rundeck v0.1.0

resource "null_resource" "generate-rundeck-int-ips" {
  count                 = "${var.RUNDECK_NODES_COUNT}"
  triggers {
    values              = "${element(google_compute_instance.rundeck.*.network_interface.0.address, count.index)}"
  }
}

resource "null_resource" "generate-rundeck-ext-ips" {
  count                 = "${var.RUNDECK_NODES_COUNT}"
  triggers {
    values              = "${element(google_compute_instance.rundeck.*.network_interface.0.access_config.0.assigned_nat_ip, count.index)}"
  }
}

locals {
  rundeck-int-ips       = "${null_resource.generate-rundeck-int-ips.*.triggers.values}"
  rundeck-ext-ips       = "${null_resource.generate-rundeck-ext-ips.*.triggers.values}"
}

resource "google_compute_instance" "rundeck" {
...
}

TF_WARN_OUTPUT_ERRORS=1 terraform plan

* local.rundeck-ext-ips: local.rundeck-ext-ips: Resource 'null_resource.generate-rundeck-ext-ips' does not have attribute 'triggers.values' for variable 'null_resource.generate-rundeck-ext-ips.*.triggers.values'
* local.rundeck-int-ips: local.rundeck-int-ips: Resource 'null_resource.generate-rundeck-int-ips' does not have attribute 'triggers.values' for variable 'null_resource.generate-rundeck-int-ips.*.triggers.values'

[mildwonkey]

Hi all!
Sorry for the long silence on this issue. This category of issue has been resolved in terraform 0.12. I can confirm that the supplied configuration now works as expected.

One minor change was required: triggers is an attribute, so you need to add = before the opening bracket.

resource "null_resource" "generate-rundeck-ext-ips" {
  count                 = "${var.RUNDECK_NODES_COUNT}"
  triggers = { 
    ...
  }
}

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