hashicorp / terraform-provider-aws

The AWS Provider enables Terraform to manage AWS resources.
https://registry.terraform.io/providers/hashicorp/aws
Mozilla Public License 2.0
9.73k stars 9.09k forks source link

Creation and deletion fails for Subnet with VPC which has different CIDR #9592

Open ghost opened 5 years ago

ghost commented 5 years ago

This issue was originally opened by @udayanms as hashicorp/terraform#22229. It was migrated here as a result of the provider split. The original body of the issue is below.


Hi there,

Each provider has it's own repository, and issues should be opened there not on the main Terraform repository.

Here are some of the most common:

*Desired State file: path DesiredState/vpc/

*file:main.tf locals { vpc_conf = { name = "MyDemo" create_vpc = false cidr = "10.11.0.0/16" secondary_cidr_blocks = ["10.12.0.0/16","10.13.0.0/16"] subnets = [ { cidr = "10.11.2.0/24" tags = { Name = "MyDemoSubnet1" purpose = "TF Automation" } }, { cidr = "10.12.2.0/24" tags = { Name = "MyDemoSubnet2" purpose = "TF Automation" } }, { cidr = "10.13.3.0/24" tags = { Name = "MyDemoSubnet3" purpose = "TF Automation" } } ] } }

module "demo_vpc" { source = "Modules/vpc" default_conf = var.default_conf vpc_conf = local.vpc_conf }

Modules: Modules/vpc main.tf

resource "aws_vpc" "vpc" { count = var.vpc_conf.create_vpc ? 1 : 0 cidr_block = var.vpc_conf.cidr

tags = { EonId = var.default_conf.eon_id Environment = var.default_conf.environment Name = var.vpc_conf.name }

}

resource "aws_vpc_ipv4_cidr_block_association" "associated_cidr" { count = var.vpc_conf.create_vpc && length(var.vpc_conf.secondary_cidr_blocks) > 0 ? length(var.vpc_conf.secondary_cidr_blocks) : 0

vpc_id = aws_vpc.vpc[0].id

cidr_block = var.vpc_conf.secondary_cidr_blocks[count.index] }

resource "aws_subnet" "prodsubnet" { count = var.vpc_conf.create_vpc && length(var.vpc_conf.subnets) > 0 ? length(var.vpc_conf.subnets) :0 vpc_id = aws_vpc.vpc[0].id cidr_block = var.vpc_conf.subnets[count.index].cidr tags = var.vpc_conf.subnets[count.index].tags }

*Output for terraform apply

module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_vpc.vpc[0]: Refr eshing state... [id=vpc-0a12d242c9b9b3bb3] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[1]: Refreshing state... [id=subnet-02f679fb3bcbb184d] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[2]: Refreshing state... [id=subnet-093d9d5300e9ae588] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[0]: Refreshing state... [id=subnet-0f9a847d5086dcb9b] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_vpc_ipv4_cidr_bl ock_association.associated_cidr[0]: Refreshing state... [id=vpc-cidr-assoc-044bc 3367867a2540] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_vpc_ipv4_cidr_bl ock_association.associated_cidr[1]: Refreshing state... [id=vpc-cidr-assoc-007bd bddf0eaccbdf]

An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols:

Terraform will perform the following actions:

module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prods ubnet[0] will be destroyed

Plan: 0 to add, 0 to change, 6 to destroy.

Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve.

Enter a value: yes

module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[1]: Destroying... [id=subnet-02f679fb3bcbb184d] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[2]: Destroying... [id=subnet-093d9d5300e9ae588] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_vpc_ipv4_cidr_bl ock_association.associated_cidr[1]: Destroying... [id=vpc-cidr-assoc-007bdbddf0e accbdf] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[0]: Destroying... [id=subnet-0f9a847d5086dcb9b] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_vpc_ipv4_cidr_bl ock_association.associated_cidr[0]: Destroying... [id=vpc-cidr-assoc-044bc336786 7a2540] module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[2]: Destruction complete after 0s module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[1]: Destruction complete after 0s module.create_us-east-1_vpc.module.call_vpc.module.demo_vpc.aws_subnet.prodsubne t[0]: Destruction complete after 0s

*Error: Error deleting VPC IPv4 CIDR block association: InvalidCidrBlock.InUse: T he vpc vpc-0a12d242c9b9b3bb3 currently has a subnet within CIDR block 10.12.0.0/ 16 status code: 400, request id: 97b10c2e-25e8-40d5-9847-785b969ce9db

*Error: Error deleting VPC IPv4 CIDR block association: InvalidCidrBlock.InUse: T he vpc vpc-0a12d242c9b9b3bb3 currently has a subnet within CIDR block 10.13.0.0/ 16 status code: 400, request id: 158310a0-26ad-43bb-afe0-1f140e78df3d

udayanms commented 5 years ago

Thanks Very much, I am not sure how it ended up there. I wanted it under AWS Provider...

mazay commented 4 years ago

@udayanms have you found any workaround for this?

andrea-defraia commented 3 years ago

I can confirm the same issue, relevant part of my code is: ` resource "aws_vpc" "main" { cidr_block = var.vpc_cidr_block instance_tenancy = var.vpc_tenancy enable_dns_hostnames = true }

resource "aws_vpc_ipv4_cidr_block_association" "additional_cidr" { count = length(var.additional_cidrs) vpc_id = aws_vpc.main.id cidr_block = var.additional_cidrs[count.index] }`

on terrafrom apply you get error: Error: error creating subnet: InvalidSubnet.Range: The CIDR '10.11.128.0/18' is invalid. status code: 400, request id: 53ccb1fd-ac4a-4d9c-8298-afebb00e42ad

and on destroy: Error: Error deleting VPC IPv4 CIDR block association: InvalidCidrBlock.InUse: The vpc vpc-0965b69ca1ba13f6d currently has a subnet within CIDR block 10.11.0.0/16 status code: 400, request id: 0c07f79a-5965-400f-95b7-83d70dd4d8e0

Workaround: apply/destroy again. It's enough to destroy twice, sometimes it takes 3 or 4 applies before it works.

Note: this happens with both TF 12 and 13, and with any AWS provider between 2.7 and 3.15

vladimir259 commented 3 years ago

Confirming, have the same issue with TF 13.5.

When deleting the secondary cidr block somehow "blocks" the VPC deletion and states

image

which is WRONG - at that point of time the subnets within this (secondary) CIDR are already deleted.

The second attempt deletes the secondary CIDR and then the VPC.

Code to reproduce:

terraform.tfvars

vpc_cidr = 10.0.0.0/20
public_subnet_azs =  ["eu-central-1a","eu-central-1b","eu-central-1c"]
k8s_pods_subnet_cidrs = ["100.64.0.0/19","100.64.32.0/19","100.64.64.0/19"]
k8s_pods_block = "100.64.0.0/17"

vpc.tf

variable "vpc_cidr" {}
variable "public_subnet_azs" { type = list }
variable "k8s_pods_block" { }
variable "k8s_pods_subnet_cidrs" { type = list }

resource "aws_vpc" "main" {
  cidr_block       = var.vpc_cidr

  instance_tenancy = "default"
  enable_dns_hostnames = true
  enable_dns_support   = true
}

resource "aws_vpc_ipv4_cidr_block_association" "secondary_cidr" {
  vpc_id     = aws_vpc.main.id
  cidr_block = var.k8s_pods_block
  depends_on = [ 
    aws_vpc.main
  ]
}

resource "aws_subnet" "k8s_pods" {
  count = length(var.k8s_pods_subnet_cidrs)
  vpc_id     = aws_vpc.main.id
  availability_zone = element(var.public_subnet_azs, count.index)
  cidr_block = element(var.k8s_pods_subnet_cidrs, count.index)

  depends_on = [
    aws_vpc.main
  ]
}
aidan-mundy commented 3 years ago

Updating to say that I am experiencing the same issue on terraform v1.0.4 with AWS provider v3.53.0. My configuration is effectively equal to those above.

marcellmartini commented 2 years ago

If you still have this problem, add to the list of depens_on the resource aws_vpc_ipv4_cidr_block_association. With the aws_vpc_ipv4_cidr_block_association resource in the depends_on list the terraform wait till the association ends and then will correctly create or delete the subnet that depends on secondary IP.