terraform plan -refresh=true vs. terraform plan -refresh=false

[boldandbusted]

I don't know if this is a local issue, but I see dramatic differences in the plan output when I pass '-refresh=false' to terraform plan, rather than the default '-refresh=true'.

Example, with -refresh=true (the default):

  + aws_iam_role_policy.[REDACTED]
      id:                                    <computed>
      name:                                  "[REDACTED]"
      policy:                                "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"s [REDACTED] }\n  ]\n}"
      role:                                  "${aws_iam_role.instance.id}"

vs.

  + aws_iam_role_policy.[REDACTED]
      id:                                                       <computed>
      name:                                                     "[REDACTED]
      policy:                                                   "${data.aws_iam_policy_document[REDACTED].json}"
      role:                                                     "${aws_iam_role.instance.id}"

and, I see data.* resources (used in the policies above) nicely broken out tabularly with '-refresh=false', but they are not shown when '-refresh=true', with " <= data.aws_iam_policy_document.logs_s3-write-only [...]"

❯ terraform --version
Terraform v0.11.3
+ provider.aws v1.1.0

This is a cosmetic bug, but would be helpful to see the output nicely parsed and presented without disabling refresh. Thanks! Happy to provide more context.

[jbardin]

Hi @boldandbusted,

If I understand the issue here correctly, you are expecting to always see the interpolation strings rather than the actual data they represent?

The latter output without refresh only shows the "${data.aws_iam_policy_document[REDACTED].json}" output because that field couldn't be resolved due to the refresh step not being run. The former output is the "more correct" output, because it shows the data changes being applied, rather than interpolation strings from the configuration.

Upcoming changes to the output may provide a better diff layout overall, but if the provider is returning a string for the change in the data, the object is to display that change to the user.

[boldandbusted]

Hi @jbardin. Actually, what I'm seeing is the opposite: I get more information (the data.* resources) when I don't run the refresh run during a plan (i.e. -refresh=false). I'm fine with seeing the interpolation only in the resources, but I miss the data.* resources. I probably should have made that clearer by including the data.* resource outputs. I hope I can put up a better example later today or tomorrow, if that's needed.

[apparentlymart]

Hi @boldandbusted!

If I'm understanding correctly, you're wondering why the <= read actions for the data resources are only displayed when -refresh=false.

Terraform tries to read data resources as early as possible. If the configuration does not depend on anything that is <computed> then it will be dealt with entirely during the refresh phase, and thus there is nothing left to do for that resource during the apply phase and Terraform will therefore omit it from the plan.

However, I've also thought before that it can sometimes be helpful to see the result of the data resource read even if it was dealt with during the refresh phase, since it can help to understand other downstream changes. Over in #17034 I wrote up some other sub-optimal aspects of how data resources are handled, and while this particular behavior is not covered there it has come up in some prototyping I did of our diff rendering, which I'll spend some more time on once we complete our current major project of integrating an improved configuration language parser.

In this particular scenario I think you wanted to see the <= read action for data.aws_iam_policy_document.logs_s3-write-only because it shows you the component parts of that IAM policy which are otherwise packed into that ugly escaped JSON string. In the shorter term (hopefully as part of the configuration language refit, but shortly afterward if not) we're planning to change the diff rendering to make data structures and multi-line strings more readable, as sketched in a comment over in #15180. This would at least make the rendered JSON in your example more readable by presenting it over multiple lines, similar to how user_data is rendered in the mockup I posted in that comment.

Given our current focus on the configuration language work we won't be able to make any immediate changes here, but I'm going to tag this so we'll remember to look back at it once we shift our focus onto improvements to the primary CLI workflow and UX.