Terraform: cycle reported when using resource attribute interpolation in local-exec destroy provisioner

Created on 2 Oct 2017  ยท  6Comments  ยท  Source: hashicorp/terraform

I have a relatively simple configuration that contains an aws_instance with a local-exec provisioner with when=destroy to cleanly shut down services and unmount an EBS Volume (that's attached via userdata). The provisioner command includes an interpolation of the aws_instance's public_ip attribute. However, an apply that replaces the instance (i.e. a user-data change) reports a cycle. The cycle disappears if I remove the provisioner or remove the interpolation from the command.

For... reasons... my use case isn't really a candidate for a remote-exec destroy provisioner.

Terraform Version

0.10.6

Terraform Configuration Files

https://github.com/jantman/tf-vol-attachment-cycle

Debug Output

See https://github.com/jantman/tf-vol-attachment-cycle

Expected Behavior

One of:

  1. (preferred) When userdata changes, terraform should replace the aws_instance as planned, without a "phantom" cycle. This is a __destroy__ provisioner, so it should know the instance's _current_ attributes (just like a connection block would).
  2. (less bad than current) Terraform __plan__ fails with an error along the lines of "Resource attribute interpolations are not permitted in provisioners for that resource".

Actual Behavior

Error applying plan:

1 error(s) occurred:

* Cycle: aws_instance.ecs-instance (destroy), aws_instance.ecs-instance

Steps to Reproduce

  1. git clone https://github.com/jantman/tf-vol-attachment-cycle.git
  2. Export AWS credentials and AWS_REGION.
  3. SUBNET_ID=<subnet-XXX> ./run.sh
bug v0.10

Most helpful comment

I _think_ I just hit this in an unrelated issue. In my case the provisioner was embedded in an aws_instance. I found that instead of referencing the parent resource directly ie through aws_instance.[name].[value] --> You can reference self.[value] which forces terraform to look at the current instance instead of the projected future one.

Seems to only work in provisioners:
https://www.terraform.io/docs/configuration/interpolation.html#attributes-of-your-own-resource

Hope this helps someone.

All 6 comments

Note that when I found it today, I _really_ thought this was a dupe of #2957. However it doesn't seem to be, as the workaround of setting skip_destroy = "true" on the aws_volume_attachment doesn't seem to work... the cycle still shows up exactly as before.

@jbardin Just a heads up that I figured out today that this issue is much simpler than I'd originally thought... it has nothing to do with the EBS Volume or Volume Attachment. It seems that the cycle shows up any time I try to interpolate a resource attribute in its own destroy-time local-exec provisioner.

@jantman: Thanks for narrowing down the scope for me.
I'll see what we can do about breaking that cycle, as I agree it seems like it should be able to work.

+1 running into this on Terraform v0.11.7. I can also confirm @jantman 's synopsis. It's worth mentioning that you might have to change "skip_destroy" = "true" in the actual TF state file (!) for a workaround.

I _think_ I just hit this in an unrelated issue. In my case the provisioner was embedded in an aws_instance. I found that instead of referencing the parent resource directly ie through aws_instance.[name].[value] --> You can reference self.[value] which forces terraform to look at the current instance instead of the projected future one.

Seems to only work in provisioners:
https://www.terraform.io/docs/configuration/interpolation.html#attributes-of-your-own-resource

Hope this helps someone.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

darron picture darron  ยท  3Comments

rjinski picture rjinski  ยท  3Comments

ronnix picture ronnix  ยท  3Comments

shanmugakarna picture shanmugakarna  ยท  3Comments

rnowosielski picture rnowosielski  ยท  3Comments