It’s not enough to only check if no new value is set. It can also be
that a new value is set, but contains a variable that cannot be
interpolated until a depending resource is created during the apply
fase.
I actually found this one as one of the acceptance tests for the AWS
ELB resource was failing. It failed with the following error:
```
--- FAIL: TestAccAWSELB_InstanceAttaching (177.83 seconds)
testing.go:121: Step 1 error: Error applying: aws_elb.bar: diffs
didn't match during apply. This is a bug with the resource provider,
please report a bug.
FAIL
exit status 1
FAIL github.com/hashicorp/terraform/builtin/providers/aws 177.882s
```
After a quick look I noticed it was actually a bug in core TF so added
the test and made sure all unit tests and AWS acceptance tests are now
running successfully.
builtin/providers/aws/tags_test.go:56: unrecognized printf verb 'i'
builtin/providers/aws/tags_test.go:59: unrecognized printf verb 'i'
config/config_test.go:101: possible formatting directive in Fatal call
config/config_test.go:157: possible formatting directive in Fatal call
config/module/get_file_test.go:91: missing argument for Fatalf(%s): format reads arg 1, have only 0 args
helper/schema/schema.go:341: arg v.Type for printf verb %s of wrong type: schema.ValueType
helper/schema/schema.go:656: missing argument for Errorf(%s): format reads arg 2, have only 1 args
helper/schema/schema.go:912: arg schema.Type for printf verb %s of wrong type: schema.ValueType
terraform/context.go:178: arg v.Type() for printf verb %s of wrong type: github.com/hashicorp/terraform/config.VariableType
terraform/context.go:486: arg c.Operation for printf verb %s of wrong type: terraform.walkOperation
terraform/diff_test.go💯 arg actual for printf verb %s of wrong type: terraform.DiffChangeType
terraform/diff_test.go:235: arg actual for printf verb %s of wrong type: terraform.DiffChangeType
Prior to this, the diff only contained changed set elements. The issue
with this is that `getSet`, the internal function that reads a set from
the ResourceData, expects that each level (state, config, diff, etc.)
has the _full set_ information. This change was done to fix merging
issues.
Because of this, we need to make sure the full set is visible in the
diff.
I know it’s very unlikely that a user will notice the difference, but
why range through the list, generate the set and calculate the
hashcode, only to find out that indexMap == nil (e.g. don’t do anything
with the generated hashcode).
As indexMap is only needed when len(parts) > 0, why not only create and
fill it (in one go) when len(parts) > 0?
This fixes a seemingly minor issue (GH-255) around plans showing changes
when in fact there are none. But in reality this turned out to uncover a
really terrible bug.
The effect of what was happening was that multiple items in a set were
being merged. Now, they were being merged in the right order, so if you
didn't have rich types (lists in a set) then you never saw the effect
since the later value would overwrite the earlier. But with lists (such
as in security groups), you would end up with the lists merging. So, if
you had one ingress rule with CIDR blocks and one with SGs, then after
the merge both ingress rules would have BOTH CIDR and SGs, resulting in
an incorrect plan (GH-255).
This fixes the issue by introducing a `getSourceExact` bitflag to the
ResourceData source. When this is set, ALL data must come from this
level, instead of merging lower levels. In the case of sets and diffs,
this is exactly what you want: "Get me the set 'foo' from the config and
the config ONLY (not the state or diff or w/e)".
Andddddd its fixed.
GH-255
Sander van Harmelen