Skip to content
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

aws_elb with a security group does not always successfully destroy #40

Closed
hashibot opened this issue Jun 13, 2017 · 4 comments · Fixed by #1427
Closed

aws_elb with a security group does not always successfully destroy #40

hashibot opened this issue Jun 13, 2017 · 4 comments · Fixed by #1427
Labels
bug Addresses a defect in current functionality.

Comments

@hashibot
Copy link

This issue was originally opened by @bitglue as hashicorp/terraform#3758. It was migrated here as part of the provider split. The original body of the issue is below.


A configuration which creates a security group which is used by an ELB also created in the same configuration won't always destroy successfully.

When an ELB is destroyed, its network interfaces can take a while to go away (some minutes). And these network interfaces reference the security group, so the security group can't be deleted until the network interfaces are gone.

Sometimes this problem is masked since Terraform has started retrying anything that results in a DependencyViolation. But eventually this retry times out, and sometimes it times out before the ELB's network interfaces have gone away, and then you'll get an error like:

Error applying plan:

1 error(s) occurred:

* aws_security_group.www_elb: DependencyViolation: resource sg-1945f97f has a dependent object
        status code: 400, request id: 
@hashibot hashibot added the bug Addresses a defect in current functionality. label Jun 13, 2017
@hashibot
Copy link
Author

This comment was originally opened by @rcha86 as hashicorp/terraform#3758 (comment). It was migrated here as part of the provider split. The original comment is below.


I'm seeing the same issue but I don't think it is necessarily related to the ELB. My terraform script creates a security group but has no mention of the network interfaces. The network interfaces seem to be created automatically by the lambda associated with the security group. I think in both of these cases, AWS decides it needs to create network interfaces and attaches them to the security group for the resource that requires it. In my case, that is the lambda. In bitglue's case, it is the ELB. I say AWS decides because the network interface is not tied to an Instance, which I thought was required.

Seems like a hairy issue, but terraform might need to figure out when it is okay and when it is not okay to detach and delete the network interfaces attached to a security group.

@michaelarichard
Copy link

I've run into this same issue with an ALB and the attached interface. It fails to destroy intermittently issuing the same sg dependent object error. Investigation in the console shows an existing network interface which must be removed manually once terraform fails.

@radeksimko
Copy link
Member

Hi @bitglue
thanks for reporting this issue.

Despite the behaviour being caused by internal (undocumented) AWS processes as @rcha86 mentioned, we have a fix in place for ELB already. ALB is pending review and Lambda received a similar fix a while back.

This will be closed automatically once #1427 is merged.
Let me know if the problem persists after the mentioned patches.

@ghost
Copy link

ghost commented Apr 11, 2020

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

@ghost ghost locked and limited conversation to collaborators Apr 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants