Terraform: Plan shows the wrong number of resources to add/change/destroy

[iroller]

Hi there,

I noticed terraform plan showing the wrong output. It does show the proper resources to be changed but not the number of resources to add/change/destroy.

Tested both in latest stable v.0.6.16 and in latest master build. The change was only in tags.Name.

$ terraform --version
Terraform v0.6.16

$ terraform plan
~ module.networking.aws_security_group.sg_allow_corp_nets
    tags.Name: "app_allow_corp_nets" => "app_allow_corp_test_nets"

Plan: 2 to add, 3 to change, 2 to destroy.

$ terraform-latest --version
Terraform v0.7.0-dev (3f0650b58547c5540f85447f76c08b84b0acda67)

$ terraform-latest plan
~ module.networking.aws_security_group.sg_allow_corp_nets
    tags.Name: "app_allow_corp_nets" => "app_allow_corp_test_nets"

~ module.compute.aws_elb.elb
    cross_zone_load_balancing: "false" => "true"

Plan: 2 to add, 4 to change, 2 to destroy.

Result of apply (applied using terraform v0.6.16):

module.networking.aws_security_group.sg_allow_corp_nets: Modifying...
  tags.Name: "app_allow_corp_nets" => "app_allow_corp_test_nets"
module.networking.aws_security_group.sg_allow_corp_nets: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

After apply:

# v0.6.16
$ terraform plan
No changes. Infrastructure is up-to-date.

# master 3f0650b58547c5540f85447f76c08b84b0acda67
$ terraform plan
~ module.compute.aws_elb.elb
    cross_zone_load_balancing: "false" => "true"

Plan: 2 to add, 3 to change, 2 to destroy.

[stack72]

Hi @iroller

I can let you know that

~ module.compute.aws_elb.elb
    cross_zone_load_balancing: "false" => "true"

Was a change introduced today to master and documented as a known potential breaking change. So we can certainly know that one is expected. Are you using any of the data_source work within your module?

P.

[iroller]

Hey,

Thanks for letting me know. I didn't expect terraform built from master to work 100% properly. Just wanted to provide outputs from both stable and latest versions to make sure it's not something fixed in the latest version. Mostly concerned about incorrect numbers in Plan: 2 to add, 3 to change, 2 to destroy..

Not using data_source at all.

[orclev]

Seeing a similar issue with v0.6.16. I think it's related to another bug I'm currently researching (and possibly opening a ticket about) related to incorrectly flagging EC2 instances as needing to be re-created on every run if they have a security group assigned to them (it seems to think there are no security groups assigned to the instance).

The numbers were _mostly_ correct originally, then as a work around to the previously mentioned issued I added

lifecycle {
  ignore_changes = ["security_groups"]
}

to a number of my resources and now it looks like it still reports the numbers as if I hadn't made that change, even though the details of what would change _do_ reflect that change.

[zommerfelds]

Had a similar issue on 0.9.8. Output was

4 to add, 4 to change, 0 to destroy.

But it only showed 2 resources to add and 4 to change in the list. Applying (without using a saved plan) showed the right summary (2, 4, 0).

P.S. We're not using security groups

[apparentlymart]

Hi all! Sorry about the weirdness here.

I think this is the same issue as #14905. A fix is in progress for this in #15344 and we're planning to get this in for the next release.

In the mean time, I can confirm that this is entirely a cosmetic issue -- some work Terraform does during refresh is being erroneously tallied as extra resources to create -- and has no impact on Terraform's behavior aside from the incorrect count. However, we know that this incorrect count is disconcerting and will get it fixed soon.

I'm going to close this just to consolidate the discussion over in #14905. Thanks for reporting this, and sorry again for the confusing behavior.

[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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.