Terraform-provider-aws: aws_autoscaling_group: diffs didn't match during apply.

[marcinowski]

Terraform Version

Terraform Version: 0.11.0

Affected Resource(s)

• aws_autoscaling_group

Terraform Configuration Files

https://gist.github.com/marcinowski/4947f3e7e7e1a0938c00d7e02a35f8ef#file-main-tf

Debug Output

https://gist.github.com/marcinowski/4947f3e7e7e1a0938c00d7e02a35f8ef#file-error-log

Expected Behavior

Content should apply.

Actual Behavior

With the first terraform apply this error is raised. After I run terraform apply the second time it works and doesn't raise this error.

Steps to Reproduce

1. terraform apply // this raises an error on autoscaling_group
2. terraform apply // this applies autoscaling_group without an error.

Important Factoids

Nothing I can think of

References

GH-2435 probably

[crzo]

I am trying to migrate from my old terraform version to the current one (0.11) and i am also having this issue.

Is there a workaround for the time being?

[marcinowski]

@crzo As I've mentioned, it crashes only the first time I apply changes, the second time I call it, it works fine.

[crzo]

@marcinowski yes i know. same for me. unfortunately thats not a acceptable workaround, because we integrated the rollout in a jenkins job and trigger it twice is not really the way to go :-)

hopefully a fix will come soon.

[apparentlymart]

Hi @marcinowski! Sorry for this strange behavior.

It does look like this is the same problem as #2453, so I'm going to close this one just to consolidate the discussion over there.

[apparentlymart]

Actually, on second thought I'm going to reopen this since it these two problems do look subtly different based on the details in the error message.

[apparentlymart]

I don't yet have a full explanation for this, but as a note for a future person looking into this in more detail:

The "Diff Two" in the error message seems to be missing the availability_zones attribute diff altogether, whereas in "Diff One" it is as follows:

        "availability_zones.#": *terraform.ResourceAttrDiff{
            Old: "",
            New: "2",
            NewComputed: false,
            NewRemoved: false,
            NewExtra: interface {}(nil),
            RequiresNew: false,
            Sensitive: false,
            Type: 0x0
        },
        "availability_zones.3148583350": *terraform.ResourceAttrDiff{
            Old: "",
            New: "ap-southeast-2a",
            NewComputed: false,
            NewRemoved: false,
            NewExtra: interface {}(nil),
            RequiresNew: false,
            Sensitive: false,
            Type: 0x0
        },

Terraform saves the diff as part of its plan (which, in the case of terraform apply with no arguments, is implicitly created and maintained only in memory) but it then generates a new diff during the apply step in order to incorporate new values that were <computed> at plan time. This error results if that second diff has different attributes (other than those that were <computed> in the first diff), since that should never happen.

It's not entirely clear why the second diff in this case would omit the availability_zones attribute, since it's set from a variable and thus I don't know why it should see a different result on that second diff. It seems like there's something subtle going on here.

@crzo did I understand correctly that you saw this behavior start only after upgrading to Terraform 0.11? If so, did you also upgrade the AWS provider at the same time, or did the AWS provider version stay constant through the upgrade?

[apparentlymart]

This seems to be the same as #1630 where there's some more background info and some workarounds documented, so I'm going to close this to consolidate the discussion over there. (For real, this time!)

If either of you have more info, please do share it in the other issue so we can collect all this info in one place. Thanks again for reporting this!

[hashibot[bot]]

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!