Terraform-provider-aws: 0.10.8 vpc security group recreating

Created on 16 Nov 2017  ·  13Comments  ·  Source: hashicorp/terraform-provider-aws

_This issue was originally opened by @alter as hashicorp/terraform#16669. It was migrated here as a result of the provider split. The original body of the issue is below._


Terraform Version

Terraform v0.10.8

Terraform Configuration Files

resource "aws_instance" "devnet-terraform-aws" {
  provider = "aws"
  instance_type = "${var.aws_instance_type}"
  ami = "${lookup(var.aws_amis, var.aws_region)}"
  key_name = "${var.aws_key_name}"
  vpc_security_group_ids = ["${lookup(var.aws_security_group, var.aws_region)}"]
  count = "${var.instance_amount}"
  tags {
    Name = "devnet-terraform"
  }
  root_block_device {
    volume_size = "${var.default_disk_size}"
    volume_type = "gp2"
  }

Expected Behavior

0 changes.

Actual Behavior


  ~ module.ec2_instances_to.aws_instance.devnet-terraform-aws[6]
      vpc_security_group_ids.#:          "0" => "1"
      vpc_security_group_ids.3081345965: "" => "sg-b83618de"

  ~ module.ec2_instances_to.aws_instance.devnet-terraform-aws[7]
      vpc_security_group_ids.#:          "0" => "1"
      vpc_security_group_ids.3081345965: "" => "sg-b83618de"

  ~ module.ec2_instances_to.aws_instance.devnet-terraform-aws[8]
      vpc_security_group_ids.#:          "0" => "1"
      vpc_security_group_ids.3081345965: "" => "sg-b83618de"

  ~ module.ec2_instances_to.aws_instance.devnet-terraform-aws[9]
      vpc_security_group_ids.#:          "0" => "1"
      vpc_security_group_ids.3081345965: "" => "sg-b83618de"

bug servicec2

Most helpful comment

I am having the same issue.

All 13 comments

I am having the same issue.

@alter @adespain - what is the behavior for the actual instance? Does it have the expected SG attached? Is the SG not in a VPC?

Attached and it's in vpc

@bflad I've also experienced this issue, and can give you a few more details about my experience.

  • I've tried this against Terraform 0.10.8 and 0.11.0, along with terraform-provider-aws 1.0, and 1.3.1.
  • My state file also was correct, it recorded the correct number of security groups, and the correct security group IDs

    • The instance itself was also in the correct state, there was the correct number of security groups and the security groups on the instance were unaltered and correct

    • I attempted to add the security groups to the instance using aws_network_interface_sg_attachment to attach on the primary network interface returned by aws_instance instead of aws_instance.vpc_security_group_ids. Each plan/apply still suggests an update to aws_network_interface_sg_attachment.security_group_id.

Also:

  • I don't believe this happened with Terraform 0.9.8, I'm in the process of verifying this

@bflad instance is ok, only this bug is annoying, b/c nothing changes.

I have the same problem with Terraform 0.10.7.

I take my current terraform configuration, I apply it. Then I do not modify anything anywhere, I run "terraform plan", and I get:

  ~ module.ecs.aws_instance.ecs_instance
      vpc_security_group_ids.#:          "0" => "1"
      vpc_security_group_ids.1616167143: "" => "sg-a5950fde"

EDIT: after upgrading to Terraform 0.11.0, I still get the same behaviour, I can apply and apply again, this "modification" always occurs.

+1

+1

@bflad any update on this?

Possible duplicate of:

  • #1799
  • #1993

@dhinus this does appear as a dupe of #1799 and #1993

Hi everyone! Sorry you have been having trouble with this aws_instance bug relating to vpc_security_group_ids. It turns out this has been reported and discussed in quite a few separate issues (#1445, #1799, #1993, #2034, #2036, #2319). In order to consolidate efforts, I am closing everything except #1993 which seems to have the most thorough information at the moment. I would suggest voting on and following that issue for future updates.

Due to the high volume of reports surrounding this, the maintainers will be looking into this sometime in the near future (including the already open PRs: #1911, #2338). There are some nuances around this configuration that make it harder than a quick fix and we certainly do not want to make the situation worse. We'll keep you updated.

As a friendly reminder: voting with 👍 reactions on the original issue/PR comment is the best way to get our attention.

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!

Was this page helpful?
0 / 5 - 0 ratings