Differences on aws_opsworks_custom_layer ebs_volume do not generate new plans

[hashibot]

This issue was originally opened by @jwieringa as hashicorp/terraform#12386. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

$ terraform --version
Terraform v0.8.6

Affected Resource(s)

• aws_opsworks_custom_layer

Terraform Configuration Files

resource "aws_opsworks_custom_layer" "app" {
  name                      = "app"
  short_name                = "app"
  stack_id                  = "${aws_opsworks_stack.default.id}"
  custom_security_group_ids = ["${aws_security_group.allow_all.id}"]

  ebs_volume = {
    mount_point = "/mnt/data"

    // Issue: The value `size` is not updated when changed
    size            = 100
    number_of_disks = 1
    raid_level      = "None"
    type            = "gp2"
  }

  # network
  auto_assign_elastic_ips = false
  auto_assign_public_ips  = false
  drain_elb_on_shutdown   = true

  # chef
  custom_setup_recipes     = []
  custom_configure_recipes = []
  custom_deploy_recipes    = []
  custom_undeploy_recipes  = []
  custom_shutdown_recipes  = []
}

Expected Behavior

Durring plan and apply, ebs_volume.size is changed when the configuration file changes.

Actual Behavior

Durring plan and apply, ebs_volume.size is not changed. This can be worked around by deleting the resource manually in AWS at which point Terraform picks up the missing configuration and applies the new setting correctly.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. Edit ebs_volume.size to 200
3. terraform plan results in no diff

[timvisher]

I just encountered this as well. I'd be happy to poke at a solution if someone wanted to point me in the right direction.

[bflad]

Hi @timvisher 👋 The fix for this should be somewhere in the neighborhood of removing (or worst case: updating) the Set function attached to the ebs_volume attribute here: https://github.com/terraform-providers/terraform-provider-aws/blob/cd087181c4be6f62e3e626e3f32f6c6eb28b7044/aws/opsworks_layers.go#L206-L209

Terraform uses the set hash to determine if a configuration block needs updates. Since the set hash remains consistent between updates of all the nested attributes except mount_point currently, Terraform will never show the appropriate update.

This type of change could cause unexpected issues though since Terraform will start performing the appropriate "drift detection" of all the ebs_volume nested attributes. If they all have the appropriate defaults, this should not be an issue other than potentially prompting operators to fix their Terraform configurations to match any customizations.

To ensure this is appropriately covered, we'll want to ensure there is a new acceptance test that attempts to update the size. 👍

Hope this helps.

[timvisher]

@bflad Thank you very much. That's extremely helpful. Could you possibly also point me towards where the acceptance test should be located?

[bflad]

@timvisher acceptance tests for the aws_opsworks_custom_layer resource can be found in: aws/resource_aws_opsworks_custom_layer_test.go -- a typical approach for adding new tests can be done via the copy-paste-modify approach. 😄

[bflad]

You may also find the Contributing Guide section on acceptance testing helpful.

[timvisher]

Wonderful. If I can't get this together it's all on me now. ;P

[bflad]

@timvisher 🎉 one caution -- the existing acceptance testing for that resource has hardcoded values for elements inside the ebs_volume configuration blocks, e.g.

resource.TestCheckResourceAttr(resourceName, "ebs_volume.3575749636.type", "gp2"),
resource.TestCheckResourceAttr(resourceName, "ebs_volume.3575749636.number_of_disks", "2"),
resource.TestCheckResourceAttr(resourceName, "ebs_volume.3575749636.mount_point", "/home"),
resource.TestCheckResourceAttr(resourceName, "ebs_volume.3575749636.size", "100"),
resource.TestCheckResourceAttr(resourceName, "ebs_volume.3575749636.encrypted", "false"),

The hash value (3575749636 in the above, different in other tests) will be changing and its no longer easy to get the value in the testing framework. We have been moving away from this type of testing in preference of using ImportStateVerify testing, e.g. having the following TestStep in the test:

{
    ResourceName:      resourceName,
    ImportState:       true,
    ImportStateVerify: true,
},

Feel free to remove the acceptance test checks that include those hardcoded ebs_volume.XXX.attribute hash values, but keeping the one that verifies the number of elements:

resource.TestCheckResourceAttr(resourceName, "ebs_volume.#", "1"),

Thanks!

[Kattyi]

Hello, any updates on this issue? I still experience size not being detected when running the plan in version 3.64.2. Is there any workaround?