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

r/resource_aws_subnet: increase deletion timeout #1051

Closed
wants to merge 1 commit into from

Conversation

s-urbaniak
Copy link

This adds a bump in the timeout for removing subnets as we experienced a high flake count upon cluster destruction. Introducing this timeout reduces flakes significantly

This is a stop-gap solution until resource providers get timeout override support.

Fixes coreos/tectonic-installer#1245

/cc @radeksimko @jasminSPC

@radeksimko
Copy link
Member

See #1052 (comment)

@radeksimko radeksimko added bug Addresses a defect in current functionality. waiting-response Maintainers are waiting on response from community or contributor. labels Jul 4, 2017
@radeksimko
Copy link
Member

Hi @s-urbaniak
as discussed in other places and conversations - raising the timeout should always be the last option unless the API explicitly exposes state (e.g. pending), so we know for sure it's worth waiting.

This isn't subnet's case, so I believe it's avoidable. We want to prevent users with genuine dependency violations from waiting too long until they see the error.

By looking at the resources you use in tectonic-installer I think there's a chance it was already addressed in either #1427 or #1036

Generally speaking one of the most common reasons I bumped into this error is when AWS service managing its own ENIs left some interfaces around after deleting the resource (e.g. VPC-enabled Lambda, ELB, ALB, ...). Unfortunately this is also the reason why it's so hard to find the root cause.

With that I'm going to close this issue, but I'd advise you to run the destruction part of your smoke tests like this:

aws ec2 describe-network-interfaces --filters=Name=vpc-id,Values=$VPC_ID | tee network-interfaces-before.json
terraform destroy ...
aws ec2 describe-network-interfaces --filters=Name=vpc-id,Values=$VPC_ID | tee network-interfaces-after.json

so that we can inspect ENIs present before and after deletion if you do bump into this error again.

@radeksimko radeksimko closed this Oct 9, 2017
@s-urbaniak
Copy link
Author

@radeksimko thanks a lot for the heads-up! I am very glad and thankful to see this going forward, hence I am fine with closing this then. We are already using stock terraform without custom patches like this one in our pipeline now too.

/cc @cpanato @mxinden can we add Radek's hint to use aws ec2 describe-network-interfaces ... to our CI pipeline and add trace points in destroy failure loops to enable ENI inspection?

mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Oct 17, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
@mxinden
Copy link

mxinden commented Oct 17, 2017

@s-urbaniak coreos/tectonic-installer#2157 addresses this.

@radeksimko Thanks a lot for your help and advice!

mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Oct 25, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Oct 27, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Oct 27, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Oct 30, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Oct 30, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Nov 1, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
mxinden added a commit to mxinden/tectonic-installer that referenced this pull request Nov 9, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
s-urbaniak pushed a commit to coreos/tectonic-installer that referenced this pull request Nov 10, 2017
For better upstream Terraform debugging we would like to log the network
interfaces related to the VPC. For further details see:
hashicorp/terraform-provider-aws#1051
@ghost
Copy link

ghost commented Apr 10, 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 10, 2020
@breathingdust breathingdust removed the waiting-response Maintainers are waiting on response from community or contributor. label Sep 17, 2021
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 this pull request may close these issues.

aws flake aws_subnet.*: timeout
4 participants