Terraform-provider-aws: Upgrading to Terraform v0.12 caused unexpected plan

Created on 8 Nov 2019  路  7Comments  路  Source: hashicorp/terraform-provider-aws

After upgrading my Terraform and corresponding configurations to v0.12, I see an unexpected difference in my plan output where an existing AWS launch configuration will be replaced with one that will also attach an EBS volume to any new instance launched by the configuration.

  # aws_launch_configuration.asg_conf must be replaced
+/- resource "aws_launch_configuration" "asg_conf" {
        associate_public_ip_address      = true
      ~ ebs_optimized                    = false -> (known after apply)
        enable_monitoring                = true
        iam_instance_profile             = "arn:aws:iam::024042545287:instance-profile/GenericWeb"
      ~ id                               = "zis-staging-web-eyojjhetjzc53aujvk52oz65xy" -> (known after apply)
        image_id                         = "ami-005436576105bd189"
        instance_type                    = "m4.xlarge"
        key_name                         = "GFS_Default"
      ~ name                             = "zis-staging-web-eyojjhetjzc53aujvk52oz65xy" -> (known after apply)
        name_prefix                      = "zis-staging-web-"
        security_groups                  = [
            "sg-bdaf38d8",
            "sg-febab382",
        ]
      ~ user_data                        = "c140dc3e8cb02959adc928410ba5932b2b509a02" -> "78553c8c05e8d9570836405c645abadda7198941" # forces replacement
      - vpc_classic_link_security_groups = [] -> null

      + ebs_block_device {
          + delete_on_termination = (known after apply)
          + device_name           = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + no_device             = (known after apply)
          + snapshot_id           = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }

      ~ root_block_device {
            delete_on_termination = true
          ~ encrypted             = false -> (known after apply)
          ~ iops                  = 0 -> (known after apply)
            volume_size           = 50
            volume_type           = "gp2"
        }
    }

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 v0.12.13
+ provider.aws v2.35.0

Affected Resource(s)

  • aws_launch_configuration

Terraform Configuration Files

resource "aws_launch_configuration" "asg_conf" {
  depends_on = [
    aws_security_group.sg]

  name_prefix = "${var.service_name}-${var.service_env}-web-"
  image_id = var.ami
  instance_type = var.sku
  key_name = var.key_name
  root_block_device {
    volume_type = var.volume_type
    volume_size = var.volume_size
    delete_on_termination = true
  }
  security_groups = [
    var.default_sg_id,
    aws_security_group.sg.id,
  ]
  iam_instance_profile = var.instance_profile
  associate_public_ip_address = true
  user_data = file("userdata.sh")

  lifecycle {
    create_before_destroy = true
  }
}

Debug Output

Panic Output

Expected Behavior

There should not have been ebs_block_device added to our aws_launch_configuration resource.

Actual Behavior

An ebs_block_device attribute was added to our aws_launch_configuration resource.

Steps to Reproduce

  1. terraform 0.12upgrade
  2. terraform init
  3. terraform plan

Important Factoids

I expect my userdata to change because I performed some configuration cleanup where I replaced the previous userdata.mime file that contained two parts to a single userdata.sh script. I believe the change in userdata could have cause this discrepancy.

References

bug servicautoscaling

Most helpful comment

I have the same issue here :face_with_head_bandage:

It's the output from plan

resource "aws_launch_configuration" "ecs-launch-configuration" {
      ~ arn                              = "arn:aws:autoscaling:<region><account>:launchConfiguration:<id>:launchConfigurationName/ecs-launch-configuration-<id>" -> (known after apply)
        associate_public_ip_address      = true
      ~ ebs_optimized                    = false -> (known after apply)
        enable_monitoring                = true
        iam_instance_profile             = "ecs-instance-profile"
      ~ id                               = "ecs-launch-configuration-<id>" -> (known after apply)
        image_id                         = "ami-05085b57e47cdc27d"
        instance_type                    = "t2.micro"
      + key_name                         = (known after apply)
      ~ name                             = "ecs-launch-configuration-<id>" -> (known after apply)
        name_prefix                      = "ecs-launch-configuration-"
        security_groups                  = [
            "sg-32323232323",
        ]
      ~ user_data                        = "<id>" -> "<id>" # forces replacement
      - vpc_classic_link_security_groups = [] -> null

      + ebs_block_device {
          + delete_on_termination = (known after apply)
          + device_name           = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + no_device             = (known after apply)
          + snapshot_id           = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }

      ~ root_block_device {
            delete_on_termination = true
          ~ encrypted             = false -> (known after apply)
          ~ iops                  = 0 -> (known after apply)
            volume_size           = 100
            volume_type           = "standard"
        }
    }

Is there some fix/workaround to this problem?

I'm running with the version 0.12.16 of Terraform and 2.66.0 of AWS Provider

All 7 comments

Downgraded back to the original version:

Terraform v0.11.14
+ provider.aws v2.35.0
-/+ aws_launch_configuration.asg_conf (new resource required)
      id:                                        "zis-staging-web-eyojjhetjzc53aujvk52oz65xy" => <computed> (forces new resource)
      associate_public_ip_address:               "true" => "true"
      ebs_block_device.#:                        "0" => <computed>
      ebs_optimized:                             "false" => <computed>
      enable_monitoring:                         "true" => "true"
      iam_instance_profile:                      "arn:aws:iam::024042545287:instance-profile/GenericWeb" => "arn:aws:iam::024042545287:instance-profile/GenericWeb"
      image_id:                                  "ami-005436576105bd189" => "ami-005436576105bd189"
      instance_type:                             "m4.xlarge" => "m4.xlarge"
      key_name:                                  "GFS_Default" => "GFS_Default"
      name:                                      "zis-staging-web-eyojjhetjzc53aujvk52oz65xy" => <computed>
      name_prefix:                               "zis-staging-web-" => "zis-staging-web-"
      root_block_device.#:                       "1" => "1"
      root_block_device.0.delete_on_termination: "true" => "true"
      root_block_device.0.encrypted:             "false" => <computed>
      root_block_device.0.iops:                  "0" => <computed>
      root_block_device.0.volume_size:           "50" => "50"
      root_block_device.0.volume_type:           "gp2" => "gp2"
      security_groups.#:                         "2" => "2"
      security_groups.183258123:                 "sg-febab382" => "sg-febab382"
      security_groups.2505743259:                "sg-bdaf38d8" => "sg-bdaf38d8"
      user_data:                                 "c140dc3e8cb02959adc928410ba5932b2b509a02" => "78553c8c05e8d9570836405c645abadda7198941" (forces new resource)

I have also upgraded my project to terraform 0.12 but did not see this difference in the plan...

However, I've just confirmed that if I update my userdata file and run the plan, I get a similar diff plan for my aws_launch_configuration:

  • an ebs_block_device is created out of thin air; and
  • iops and encrypted fields of the root_block_device suddenly appear...
  • and all the other oddities reported in the plan above...

Also running terraform 0.12.13 and aws provider 2.35

same issue here.
upgraded terraform from 0.11.11 to latest(0.12.16) and noticed this issue while running plan.

simplified tf file:

resource "aws_launch_configuration" "some_asg_conf" {
  name_prefix   = "some-prefix"
  image_id      = "input-ami"
  instance_type = "input-instance-type"
  key_name      = "input-key-name"
  root_block_device {
    volume_type           = "gp2"
    volume_size           = 80
    delete_on_termination = true
  }
  security_groups = [
    "some-securty-group0",
    "some-securty-group1",
  ]
  iam_instance_profile        = "input-instance-profile"
  associate_public_ip_address = true
  user_data                   = file("some-userdata.sh")

  lifecycle {
    create_before_destroy = true
  }
}

and output from terraform plan:

# aws_launch_configuration.asg_conf must be replaced
+/- resource "aws_launch_configuration" some_asg_conf {
       associate_public_ip_address      = true
     ~ ebs_optimized                    = false -> (known after apply)
       enable_monitoring                = true
       iam_instance_profile             = "input-instance-profile"
     ~ id                               = "some-instance-id" -> (known after apply)
     ~ image_id                         = "old-ami" -> "input-ami" # forces replacement
       instance_type                    = "m5.2xlarge"
       key_name                         = "input-key-name"
     ~ name                             = "some-name" -> (known after apply)
       name_prefix                      = "some-prefix"
       security_groups                  = [
           "some-securty-group0",
           "some-securty-group1",
       ]
       user_data                        = "some-userdata-hash"
     - vpc_classic_link_security_groups = [] -> null
     + ebs_block_device {
         + delete_on_termination = (known after apply)
         + device_name           = (known after apply)
         + encrypted             = (known after apply)
         + iops                  = (known after apply)
         + no_device             = (known after apply)
         + snapshot_id           = (known after apply)
         + volume_size           = (known after apply)
         + volume_type           = (known after apply)
       }
     ~ root_block_device {
           delete_on_termination = true
         ~ encrypted             = false -> (known after apply)
         ~ iops                  = 0 -> (known after apply)
           volume_size           = 80
           volume_type           = "gp2"
       }
   }

intention was to simply update the image_id (ami) and this additional ebs_block_device is totally unexpected.

After looking more closely at the plan for a launch config computed by terraform 0.11, I noticed similar oddities:


-/+ module.aws_launch_configuration.my_asg (new resource required)
      id:                                        "my-asg" => <computed> (forces new resource)
      associate_public_ip_address:               "false" => "false"
      ebs_block_device.#:                        "0" => <computed>
      ebs_optimized:                             "true" => "true"
      enable_monitoring:                         "true" => "true"
      iam_instance_profile:                      "my-instance-profile" => ""my-instance-profile"
      image_id:                                  "ami-abcd" => "ami-fghi" (forces new resource)
      instance_type:                             "c5.2xlarge" => "c5.2xlarge"
      key_name:                                  "my-key" => "my-key"
      name:                                      "my-asg" => <computed>
      name_prefix:                               "my-asg" => "my-asg"
      root_block_device.#:                       "1" => "1"
      root_block_device.0.delete_on_termination: "true" => "true"
      root_block_device.0.encrypted:             "false" => <computed>
      root_block_device.0.iops:                  "0" => "0"
      root_block_device.0.volume_size:           "25" => "25"
      root_block_device.0.volume_type:           "gp2" => "gp2"
      security_groups.#:                         "1" => "1"
      security_groups.1889276821:                "sg-1234" => "sg-1234"
      user_data_base64:   

Like in the plan given by terraform 0.12, I get:

  • an unexpected computed ebs_block_device
  • an unexpected computed root_block_device.encrypted
  • iops also shows up in the plan although I did not specify it in my config

I applied the terraform 0.11 and didn't see any new ebs device attached to my ec2 instance.
I then applied another similar plan with terraform 0.12 and no new ebs device was created...

I think this issue isn't new, or at least not specific to terraform 0.12. The plan from 0.12 just better reveals the issue. Bug seems to be just plan/display related.

It also seems to be just a plan/display issue since real resources aren't created.

I have the same issue here :face_with_head_bandage:

It's the output from plan

resource "aws_launch_configuration" "ecs-launch-configuration" {
      ~ arn                              = "arn:aws:autoscaling:<region><account>:launchConfiguration:<id>:launchConfigurationName/ecs-launch-configuration-<id>" -> (known after apply)
        associate_public_ip_address      = true
      ~ ebs_optimized                    = false -> (known after apply)
        enable_monitoring                = true
        iam_instance_profile             = "ecs-instance-profile"
      ~ id                               = "ecs-launch-configuration-<id>" -> (known after apply)
        image_id                         = "ami-05085b57e47cdc27d"
        instance_type                    = "t2.micro"
      + key_name                         = (known after apply)
      ~ name                             = "ecs-launch-configuration-<id>" -> (known after apply)
        name_prefix                      = "ecs-launch-configuration-"
        security_groups                  = [
            "sg-32323232323",
        ]
      ~ user_data                        = "<id>" -> "<id>" # forces replacement
      - vpc_classic_link_security_groups = [] -> null

      + ebs_block_device {
          + delete_on_termination = (known after apply)
          + device_name           = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + no_device             = (known after apply)
          + snapshot_id           = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }

      ~ root_block_device {
            delete_on_termination = true
          ~ encrypted             = false -> (known after apply)
          ~ iops                  = 0 -> (known after apply)
            volume_size           = 100
            volume_type           = "standard"
        }
    }

Is there some fix/workaround to this problem?

I'm running with the version 0.12.16 of Terraform and 2.66.0 of AWS Provider

Well, version 0.13 was released but this issue is still open. We're in version 0.11.X because of this. Is there some workaround?

Experiencing this same thing. Running v0.12.24 where a root block device exists:

  root_block_device {
    volume_type                 = "gp2"
    volume_size                  = var.root_block_device_volume_size
    iops                               = var.root_block_device_iops
    delete_on_termination = true
    encrypted                     = true
  }

Even after doing a tf apply successfully, subsequent plans result in changes to the resource because of iops:

...
      ~ root_block_device {
            delete_on_termination = true
            encrypted             = true
          ~ iops                  = 0 -> 960 # forces replacement
            volume_size           = 60
            volume_type           = "gp2"
        }
...

@leandrorebelo not sure if this is the best solution so far but one thing I'm doing now is to try and ignore the changes:

  lifecycle {
    ignore_changes = [
      root_block_device[0].iops
    ]
  }

Here, I'm referencing the root block device's iops field. This workaround is a little simpler because there's only one volume, but I hope this helps!

Was this page helpful?
0 / 5 - 0 ratings