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.
0.10.6
https://github.com/jantman/tf-vol-attachment-cycle
See https://github.com/jantman/tf-vol-attachment-cycle
One of:
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).Error applying plan:
1 error(s) occurred:
* Cycle: aws_instance.ecs-instance (destroy), aws_instance.ecs-instance
git clone https://github.com/jantman/tf-vol-attachment-cycle.gitAWS_REGION.SUBNET_ID=<subnet-XXX> ./run.shNote 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.
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 referenceself.[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.