terraform-provider-aws: ebs_block_device shows changes on every plan/apply after 2.7.0 update

HI!

Somewhere in the change between the 2.6.0 and 2.7.0 we have an ebs_block_device config that always shows changes to be applied for some of our instances. This is still occurring in 2.8.0.

[INFO] Switching to v0.11.13
[INFO] Switching completed
~ module.es_cluster.aws_instance.esnode[0]
    ebs_block_device.2659407853.iops:                    "3072" => ""
    ebs_block_device.2659407853.snapshot_id:             "" => "<computed>"
    ebs_block_device.2659407853.volume_id:               "vol-034b1cde3080b2a08" => "<computed>"

~ module.es_cluster.aws_instance.esnode[1]
    ebs_block_device.2659407853.iops:                    "3072" => ""
    ebs_block_device.2659407853.snapshot_id:             "" => "<computed>"
    ebs_block_device.2659407853.volume_id:               "vol-0f735193efd918596" => "<computed>"

~ module.es_cluster.aws_instance.esnode[2]
    ebs_block_device.2659407853.iops:                    "3072" => ""
    ebs_block_device.2659407853.snapshot_id:             "" => "<computed>"
    ebs_block_device.2659407853.volume_id:               "vol-0912bc7b901873436" => "<computed>"

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave “+1” or “me too” comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

terraform -v
Terraform v0.11.13
+ provider.archive v1.2.1
+ provider.aws v2.8.0
+ provider.null v2.1.1
+ provider.template v2.1.1

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

variable "data_volume_size" {
  type        = "string"
  default     = "1024"
  description = "The size of the EBS data volume to attach to the nodes"
}

variable "data_volume_delete_on_termination" {
  type        = "string"
  default     = true
  description = "Whether the data volume should be destroyed on instance termination"
}


resource "aws_instance" "esnode" {
  count                = "${var.size}"
  ami                  = "${data.aws_ami.es_ami.image_id}"
  instance_type        = "${var.instance_type}"
  ebs_optimized        = true
  subnet_id            = "${element(var.subnet_ids, count.index)}"
  user_data            = "${data.template_file.elasticsearch_userdata.rendered}"
  monitoring           = "${var.enable_monitoring}"
  iam_instance_profile = "${aws_iam_instance_profile.elasticsearch.id}"

  vpc_security_group_ids = [
    "${var.security_groups}",
    "${aws_security_group.elasticsearch.id}",
    "${aws_security_group.elasticsearch_client.id}",
  ]

  root_block_device {
    volume_type           = "gp2"
    volume_size           = "250"
    delete_on_termination = true
  }

  ebs_block_device {
    device_name           = "/dev/sdf"
    volume_type           = "gp2"
    volume_size           = "${var.data_volume_size}"
    delete_on_termination = "${var.data_volume_delete_on_termination}"
    encrypted             = true
  }

  lifecycle {
    create_before_destroy = true
    ignore_changes        = ["user_data", "ami"]
  }

  tags {
    Role        = "elasticsearch"
    Name        = "${format("esnode-%02d", count.index + 1)}"
    Environment = "${var.environment}"
    ESCluster   = "${var.name}"
  }
}

Debug Output

Our debug output is littered with secrets. Let me know if there’s someplace more secure I can send it other than GIST.

Panic Output

N/A

Expected Behavior

There were no changes to the EBS volumes, so it should just leave it alone

Actual Behavior

Every terraform plan/apply still shows changes to be done.

Steps to Reproduce

  1. terraform apply

Important Factoids

Rolling back to the 2.6.0 aws provider “fixes” this.

References

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 21
  • Comments: 24 (5 by maintainers)

Most upvoted comments

A correction for my above comment… Apparently it was security_groups that caused the above change to be trigged, thus not related to ebs_block_device:

      ~ security_groups              = [ # forces replacement
          + "sg-09bdb6f37a4cd2e4b",
        ]

The instance SG was configured as:

security_groups = [module.prometheus_sg.this_security_group_id]

(where prometheus_sgmodule is a https://github.com/terraform-aws-modules/terraform-aws-security-group). Looking at terraform show the security_groups attributes was an empty list, but the vpc_security_group_ids had the right ID. Changing instance config to use vpc_security_group_ids rather than security_groups seems to have resolved this issue, and I now need no ignore_changes.

@danbudrisef I had this issue when I was getting everything upgraded to 0.12. Since I got everything on the latest version (terraform and providers), the issue went away.

But before I completed the upgrade, I was able to suppress this issue by using ignore_changes on (iirc) iops.

So something like:

  lifecycle {
    create_before_destroy = true
    ignore_changes        = ["iops", "user_data", "ami"]
  }

Sorry I don’t remember the exact details – like I said, the issue went away from me once everything was upgraded to latest and greatest.

EDIT: versions for ref:

Terraform v0.12.2
+ provider.archive v1.2.2
+ provider.aws v2.12.0
+ provider.cloudflare v1.15.0