Terraform-provider-digitalocean: VPC fails to be destroyed as it seems not empty, but it should be

[liarco]

Terraform Version

Terraform v0.13.2
+ provider registry.terraform.io/digitalocean/digitalocean v1.22.2

Affected Resource

• digitalocean_vpc

Terraform Configuration Files

https://gist.github.com/liarco/a1fab103af843feff29903feec2b27a9

Terraform Cloud run output

https://gist.github.com/liarco/6b2990a7212968730617c64b392630ec

Expected Behavior

All resources should be deleted successfully.

Actual Behavior

The VPC cannot be deleted since it seems to be "not empty", but running terraform destroy again destroys the VPC with no error.

Steps to Reproduce

1. terraform apply wait for all resources to be provisioned...
2. terraform destroy wait until it fails...
3. terraform destroy run again to destroy the VPC successfully

Important Factoids

You must have a default VPC for the region (e.g. ams3-default) before reproducing the error, otherwise a default VPC will be created and that one cannot be deleted using terraform. This is why I don't think that my issue can be related to #472.

[andrewsomething]

It seems like Kubernetes clusters are not de-registering from the VPC immediately when deleted. I've raised this with our VPC team for investigation.

Currently the VPC resource will retry the delete call for 2 minutes before timing out, but we made that configurable. Something like this should work around the issue:

resource "digitalocean_vpc" "vpc" {
  name     = "test-network"
  region   = "ams3"

  timeouts {
    delete = "10m"
  }
}

We might want to raise the default here regardless.

[liarco]

I'm sorry for the delay, but I can confirm that a higher timeout can be a good temporary workaround, thank you!
Anyway it forces longer waits for the operations to be really performed, so a proper fix from the DO team might be the best solution.

[aybabtme]

I've been seeing the same thing, VPCs fail to delete despite having removed all resources that were in them. Re-running the deletion a few minutes later ends up working (although in the past I had a case where a VPC would simply refuse to be deleted for weeks).

Would be nice if this was fixed in the API. @adamwg do you know anything about this (😸 🚎)?

[adamwg]

I'm guessing this is due to the fact that DOKS cluster deletion is asynchronous. The cluster is marked as deleted immediately, but we delete the worker node droplets after returning. Since the worker node droplets are what's actually attached to the VPC, the VPC isn't empty until they're deleted. Usually the droplets will be deleted within the 2 minute retry window, but due to various problems they could stick around longer.

[aybabtme]

Interesting, I guess from a user's perspective it would be good to get an error from VPC explaining that some resources are still being deleted, so at least we'd know what's happening and don't think it's just broken 😅

[h3ct0rjs]

Hi everybody,

It seems that the same problem is happening to me, I'm doing simple exercises to create a small infrastructure using Digital Ocean. When I create a simple vpc in a specific region where we previously don't have a default vpc, the provider sets this vpc created with terraform as default, that is a normal behavior, the problem is that if you don't have a previous vpc as default if you run
terraform destroy it is unable to destroy the vpc resource because it's a default vpc.

Let's take for example the following code.

resource "digitalocean_vpc" "web_vpc"{
    # The human friendly name of our VPC.
    name = var.vpcname

    # The region to deploy my VPC.
    region = var.region

    # The private ip range within our VPC
    ip_range = "10.148.0.0/22"
}

adding the timeout fix the issue for me, I want to know if you're working to fix this or check other workarounds in my pipeline.

Thanks in advance,
Sincerely,
H