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

destroy > systematic DependencyViolation #497

Closed
frntn opened this issue Oct 22, 2014 · 12 comments
Closed

destroy > systematic DependencyViolation #497

frntn opened this issue Oct 22, 2014 · 12 comments

Comments

@frntn
Copy link
Contributor

frntn commented Oct 22, 2014

When trying to terraform destroy while running instance(s) with public ip(s) on a subnet inside a VPC with an Internet Gateway associated with it, each time I get the following error when trying to destroy the igw :

[...]

aws_internet_gateway.gw-to-internet: Destroying...
aws_internet_gateway.gw-to-internet: Error: Network vpc-xxxxxxxx has some mapped public address(es). Please unmap those public address(es) before detaching the gateway. (DependencyViolation)

[...]

Error applying plan:

1 error(s) occurred:

* Network vpc-xxxxxxx has some mapped public address(es). Please unmap those public address(es) before detaching the gateway. (DependencyViolation)

A full repro.tf is available here : https://gist.github.com/frntn/12126851cdc2ef1cdbaf

If this is impossible, then the internet gateway destruction attempt should occur after every public addresses are detached.

May be wait for at least :

  • each known ec2 instances with associate_public_ip_address (have to add it as attribute of aws_instance)
  • and each ec2 instances inside a subnet with map_public_ip_on_launch set to true (have to add it as attribute of aws_subnet).

But you may have better way to implement this dependency. Just saying.. :)

version: terraform v0.3.1
platform: linux 64bits (debian wheezy)

@delitescere
Copy link

Perhaps similar, I have a VPC (no instances yet) that creates fine but terraform destory provides this error:

module.vpc.aws_vpc.main: Error: Error deleting VPC: The vpc 'vpc-...' has dependencies and cannot be deleted. (DependencyViolation)

Yet I can can select the VPC in the AWS VPC Dashboard and delete it just fine.

@blakeblackshear
Copy link

This is still an issue for me in 0.3.6

@sbward
Copy link

sbward commented Jan 21, 2015

+1 I'm also seeing this exact issue (0.3.6)

@chipi
Copy link

chipi commented Jan 23, 2015

+1 ... really anoying

@korya
Copy link

korya commented Jan 27, 2015

Faced the same issue.

My workaround is to define an explicit dependency of the instances on VPC's gateway.

In my setup there are 4 instances in a VPC (www_a, www_c, db_a, db_c):

resource "aws_instance" "www_a" {
  ...
  depends_on = ["aws_internet_gateway.prd_plntr"]
}
resource "aws_instance" "www_c" {
  ...
  depends_on = ["aws_internet_gateway.prd_plntr"]
}
resource "aws_instance" "db_a" {
  ...
  depends_on = ["aws_internet_gateway.prd_plntr"]
}
resource "aws_instance" "db_a" {
  ...
  depends_on = ["aws_internet_gateway.prd_plntr"]
}

resource "aws_internet_gateway" "prd_plntr" {
  vpc_id "${aws_vpc.prd_plntr}"
}

No explicit dependency

Explicit dependency

I believe this dependency should be set implicitly by terraform.

@korya korya mentioned this issue Jan 27, 2015
@radeksimko
Copy link
Member

Here's the shortest example for reproducing the problem:

resource "aws_vpc" "default" {
  cidr_block = "10.10.0.0/16"
}

resource "aws_internet_gateway" "default" {
  vpc_id = "${aws_vpc.default.id}"
}

resource "aws_subnet" "public" {
  vpc_id = "${aws_vpc.default.id}"
  cidr_block = "10.10.0.0/24"
  availability_zone = "eu-west-1a"
}

resource "aws_instance" "nat" {
  ami = "ami-14913f63"
  availability_zone = "eu-west-1a"
  instance_type = "t2.micro"
  key_name = "radeksimko"
  subnet_id = "${aws_subnet.public.id}"
  associate_public_ip_address = true
}

If I set associate_public_ip_address = false or remove the internet gateway, the issue disappears.

It is reproducible with the very latest version v0.3.7.dev (26156981d7b67dce7a033ffea94aea5370c09c58) just by

terraform apply
terraform destroy

Simplest workaround is just to run destroy twice.

@clstokes
Copy link
Contributor

Running into this too.

👍

@catsby
Copy link
Contributor

catsby commented Mar 17, 2015

This resurfaced recently in #1203 . The workaround that resulted for this particular issue was to add a depends_on clause to the instance (as @korya suggests above). To use @radeksimko 's config example:

resource "aws_vpc" "default" {
  cidr_block = "10.10.0.0/16"
}

resource "aws_internet_gateway" "default" {
  vpc_id = "${aws_vpc.default.id}"
}

resource "aws_subnet" "public" {
  vpc_id = "${aws_vpc.default.id}"
  cidr_block = "10.10.0.0/24"
  availability_zone = "eu-west-1a"
}

resource "aws_instance" "nat" {
  ami = "ami-14913f63"
  availability_zone = "eu-west-1a"
  instance_type = "t2.micro"
  key_name = "radeksimko"
  subnet_id = "${aws_subnet.public.id}"
  associate_public_ip_address = true
  depends_on = ["aws_internet_gateway.default"] # explicit dependency 
}

Terraform is trying to move on and delete other things, but AWS API is still working on destroying things so as to not violate dependencies. Documentation was added in #1189 to document this, but that change hasn't been deployed to terraform.io yet.

I'm not sure what else can be done here. cc @phinze for ideas about implicitly setting that dependency(?)

@zxjinn
Copy link

zxjinn commented Mar 19, 2015

The way I worked around this specific issue was: I associated EIP's with my instances instead of giving them public IPs. When Terraform goes to destroy the VPC it disassociates the EIPs from the instances cleanly, then destroys the EIP. I have a small number of publicly facing instances so this works for me.

Additionally, there is no extra charge associated with EIPs as long as you are using them, however you are limited to five EIPs per region per account.

@kendawg2
Copy link

@catsby this issue is also related to #1303 for your 'thinking' tag.

@catsby
Copy link
Contributor

catsby commented Mar 27, 2015

Hey all – #1325 was just merged and should fix this. Let me know if you're still running into it on master

@catsby catsby closed this as completed Mar 27, 2015
@ghost
Copy link

ghost commented May 3, 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 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.

@ghost ghost locked and limited conversation to collaborators May 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests