New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cycle reported when using resource attribute interpolation in local-exec destroy provisioner #16237

Open
jantman opened this Issue Oct 2, 2017 · 5 comments

Comments

Projects
None yet
4 participants
@jantman

jantman commented Oct 2, 2017

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

@jbardin jbardin added atlas bug and removed atlas labels Oct 2, 2017

@jantman

This comment has been minimized.

Show comment
Hide comment
@jantman

jantman Oct 3, 2017

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.

jantman commented Oct 3, 2017

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.

@jantman jantman changed the title from unexpected cycle - aws_instance local-exec provisioner when=destroy to cycle reported when using resource attribute interpolation in local-exec destroy provisioner Oct 5, 2017

@jantman

This comment has been minimized.

Show comment
Hide comment
@jantman

jantman Oct 5, 2017

@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 commented Oct 5, 2017

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

@jbardin

This comment has been minimized.

Show comment
Hide comment
@jbardin

jbardin Oct 5, 2017

Contributor

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

Contributor

jbardin commented Oct 5, 2017

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

@robax

This comment has been minimized.

Show comment
Hide comment
@robax

robax May 23, 2018

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

robax commented May 23, 2018

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

@kingsquirrel152

This comment has been minimized.

Show comment
Hide comment
@kingsquirrel152

kingsquirrel152 Jun 28, 2018

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.

kingsquirrel152 commented Jun 28, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment