Terraform apply fails when renaming aws_security_group

[paul-gitseed]

Issue #2117 was closed as unreproducible. I'm able to reproduce this bug and I run into it extremely frequently in 0.6.3.

To reproduce, clone this repo:
https://github.com/paul-gitseed/terraformbug

Run: reproduce.bash

Output:

admin@ip-172-31-18-149:~/terraformbug$ ./reproduce.bash
aws_security_group.onefish: Creating...
  description:                        "" => "This reproduces a bug in terraform."
  egress.#:                           "" => "1"
  egress.482069346.cidr_blocks.#:     "" => "1"
  egress.482069346.cidr_blocks.0:     "" => "0.0.0.0/0"
  egress.482069346.from_port:         "" => "0"
  egress.482069346.protocol:          "" => "-1"
  egress.482069346.security_groups.#: "" => "0"
  egress.482069346.self:              "" => "0"
  egress.482069346.to_port:           "" => "0"
  ingress.#:                          "" => "<computed>"
  name:                               "" => "redfish"
  owner_id:                           "" => "<computed>"
  vpc_id:                             "" => "<computed>"
aws_security_group.onefish: Creation complete
aws_instance.twofish: Creating...
  ami:                                       "" => "ami-818eb7b1"
  availability_zone:                         "" => "<computed>"
  ebs_block_device.#:                        "" => "<computed>"
  ephemeral_block_device.#:                  "" => "<computed>"
  instance_type:                             "" => "t2.micro"
  key_name:                                  "" => "<computed>"
  placement_group:                           "" => "<computed>"
  private_dns:                               "" => "<computed>"
  private_ip:                                "" => "<computed>"
  public_dns:                                "" => "<computed>"
  public_ip:                                 "" => "<computed>"
  root_block_device.#:                       "" => "1"
  root_block_device.0.delete_on_termination: "" => "1"
  root_block_device.0.iops:                  "" => "<computed>"
  root_block_device.0.volume_size:           "" => "<computed>"
  root_block_device.0.volume_type:           "" => "gp2"
  security_groups.#:                         "" => "<computed>"
  source_dest_check:                         "" => "1"
  subnet_id:                                 "" => "<computed>"
  tenancy:                                   "" => "<computed>"
  vpc_security_group_ids.#:                  "" => "1"
  vpc_security_group_ids.1611644906:         "" => "sg-538c1c37"
aws_instance.twofish: Creation complete

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: ../terraform.tfstate
aws_security_group.onefish: Refreshing state... (ID: sg-538c1c37)
aws_instance.twofish: Refreshing state... (ID: i-fb4e5a3e)
aws_security_group.onefish: Destroying...
Error applying plan:

1 error(s) occurred:

* aws_security_group.onefish: DependencyViolation: resource sg-538c1c37 has a dependent object
        status code: 400, request id: []

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

[paulcdejean]

As you can see there's several other open issues that may be related to this bug.

[lukehoersten]

What's going on here is if an EC2 instance has only this security group that you're trying to rename (delete) AWS doesn't allow it to be delated. Terraform needs to:

1. move the instances with only this SG to the default SG,
2. recreate the SG with the new name/desc,
3. reassign the SG to the instance and
4. unassociated the default SG form the instance.

[paulcdejean]

It would also be acceptable, but hardly ideal, to just recreate the
underlying instance.
On Sep 30, 2015 6:50 AM, "Luke Hoersten" notifications@github.com wrote:

What's going on here is if an instance has only this security group that
you're trying to rename (delete) AWS doesn't allow it to be delated.
Terraform needs to:

1. move the instances with only this SG to the default SG,
2. recreate the SG with the new name/desc,
3. reassign the SG to the instance and
4. unassociated the default SG form the instance.

—
Reply to this email directly or view it on GitHub
#3341 (comment)
.

[lukehoersten]

By "instance" I mean EC2 instance. Destroying and recreating an EC2 instance to change a SG name would not be acceptable for my case.

[paulcdejean]

Well if your under ec2 classic you'd have no choice. Should classic be
supported though? I think it should not be personally.
On Sep 30, 2015 7:02 AM, "Luke Hoersten" notifications@github.com wrote:

By "instance" I mean EC2 instance. Destroying and recreating an EC2
instance to change a SG name would not be acceptable for my case.

—
Reply to this email directly or view it on GitHub
#3341 (comment)
.

[keen99]

Well if your under ec2 classic you'd have no choice. Should classic be
supported though? I think it should not be personally.

I'd think classic should be supported until it doesnt exist. That said, VPC should be supported too - and the behavior of some of these is different between the two so clearly both paths should work. :)

[catsby]

Hello all!
I apologize for the silence here.

First, thank you for the example repo that demonstrates this issue! That made looking into this 3x as fast and easy 😄

AWS will not allow us to destroy the SG while an Instance is using it. The instance itself can have it's security group(s) updated without termination, if you're on a VPC. As noted, if you're running on Classic, then the instance itself must be replaced with the change of the security group.

Here we're seeing Terraform wanting to destroy, then recreate the Security group. To enable this in Terraform, you need to add a lifecycle block to the Security Group, with the create_before_destroy attribute set to true. And example config:

provider "aws" {
  region = "us-west-2"
}

resource "aws_vpc" "default" {
  cidr_block = "10.0.0.0/16"

  tags {
    Name = "tftesting"
  }
}

resource "aws_security_group" "onefish" {
  name = "bluefish"
  description = "This reproduces a bug in terraform."

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_instance" "twofish" {
  # Debian Jessie.
  # us-west
  ami = "ami-818eb7b1"
  instance_type = "t2.micro"
  security_groups = ["${aws_security_group.onefish.name}"]

  root_block_device {
    volume_type = "gp2"
  }
}

With this configuration, you can rename the security group with no issue. Terraform will create the new security group, update the instance, and then destroy the old security group.

This works in Classic as well, however, the instance is replaced instead of updated.

I'm going to close this issue for now. Thanks for opening it, I'll be reviewing the linked issues as well.

Thanks!

[paulcdejean]

Thanks catsby for the information on the workaround!

[johnhamelink]

@catsby Thanks for the information but it doesn't seem to work for me!

Without the lifecycle block:

Error applying plan:

1 error(s) occurred:

* aws_security_group.production_api_app: Error creating Security Group: InvalidGroup.Duplicate: The security group 'production_api_app' already exists for VPC 'vpc-ede5a588'
    status code: 400, request id:

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

And with the lifecycle block:

Error applying plan:

1 error(s) occurred:

* aws_security_group.production_api_app: Error creating Security Group: InvalidGroup.Duplicate: The security group 'production_api_app' already exists for VPC 'vpc-ede5a588'
    status code: 400, request id:

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

[catsby]

Hey @johnhamelink the second error shouldn't be happening, do you have a configuration that shows the lifecycle block but still gets that error?

[johnhamelink]

@catsby https://gist.github.com/johnhamelink/74b34e2a1f3cf73f5272

I discovered this issue when attempting to rename the description of the security group.

JH

[kitforbes]

This issue is still present. I used to name my security groups like dev_http, which is unique and caused issues. I started using name_prefix instead, so my security groups would have unique names.

When updating the security group by editing the description, for example, and create_before_destroy being true, Terraform will offer to recreate the security group without noticing that the collection of security groups on the instance needs to update. This results in the standard DependencyViolation error as the initial security group isn't detached and deleted.

Error applying plan:

1 error(s) occurred:

• aws_security_group.all_inbound (deposed #0): DependencyViolation: resource sg-6a39e111 has a dependent object
  status code: 400, request id: c212b128-61c5-4de9-a070-55f6df034624

[es-on-github]

I hit this error today, after trying to rename the "only" security group attached to an instance.
I also added temporarily a default security group to the instance, executed the plan again, but it still failed.
The failing plan also mismatched the state files ...
My workaround:

1. In AWS console, attach a temporary SG to the instance.
2. In AWS console, detach the problematic SG
3. In AWS console, delete the problematic SG
4. Synchronize the state files
5. Execute the plan in terraform enterprise
   Agreed with comments left at Changing AWS Security Group description forces new resource #14330 by @spanktar

[PorridgeBear]

Also ran into this. After setting create_before_destroy had the renaming issue. Took @kitforbes suggestion, removed name="foo" replaced with name_prefix="foo" and that generates a group name that is unique.

[ghost]

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.