Terraform: Let terraform plan output rendered templates

[llarsson]

I use templates to generate user-data for my instances. As part of terraform plan, I care much more about what values the bootscript will be rendered with, rather than the template I passed in.

Could we get that as part of the output (possibly instead of merely echoing the template)?

[matti]

Do you have a workaround for this?

[matti]

I'm using apply without any actual changes

[eproxus]

This would be useful to render for example host files or Ansible inventory files.

[apparentlymart]

Hi @llarsson,

I would expect that the rendered template would be visible in the diff for the user_data attribute on the instance, so you can see what you're setting it to. Is it not showing up there?

If you're still on Terraform 0.6, where template_file is a resource, then this is expected not to work because on initial creation the user_data will show up as just "<computed>" or "${template_file.foo.rendered}".

As of Terraform 0.7 template_file is a data source, so it won't actually show up in the diff at all if it's possible to render it entirely at plan time, but its result should be immediately visible in the user_data attribute diff.

If your template_file references attributes on other resources that need to be created first then we wouldn't be able to show the rendered template during plan in either case, because there isn't enough information at plan time to render the template and so this needs to wait until apply time.

[llarsson]

Hi!

I always have computed values and use Launch Configurationations, as I
pretty much always use auto scaling for high availability, if not for
scaling. So that should explain it, thanks.

Martin Atkins [email protected] skrev: (11 oktober 2016 17:54:48
CEST)

Hi @llarsson https://github.com/llarsson,

I would expect that the rendered template would be visible in the diff for
the user_data attribute on the instance, so you can see what you're
setting it to. Is it not showing up there?

If you're still on Terraform 0.6, where template_file is a resource, then
this is expected not to work because on initial creation the user_data
will show up as just "" or "${template_file.foo.rendered}".

As of Terraform 0.7 template_file is a data source, so it won't actually
show up in the diff at all if it's possible to render it entirely at plan
time, but its result should be immediately visible in the user_data
attribute diff.

If your template_file references attributes on other resources that need
to be created first then we wouldn't be able to show the rendered template
during plan in either case, because there isn't enough information at plan
time to render the template and so this needs to wait until apply time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/8669#issuecomment-252959910,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXA_n5qsvtiZ39ZqiVTXkzYH1-5canIks5qy7FIgaJpZM4J1iI2
.

[apparentlymart]

Hi @llarsson,

I think I'm understanding from your response that this answered your question, so I'm going to close this. Feel free to re-open if you have other questions/thoughts. Thanks!

[llarsson]

Well, here's the thing. With my computed values, I still get the following output indicating that Terraform knows what the values should be, but does not want to show any human-readable information about it:

aws_launch_configuration.foo_lc
    associate_public_ip_address: "false" => "false"
    ebs_block_device.#:          "0" => "<computed>"
    ebs_optimized:               "false" => "<computed>"
    enable_monitoring:           "true" => "true"
    iam_instance_profile:        "REDACTED"
    image_id:                    "ami-b3bdffc0" => "ami-b3bdffc0"
    instance_type:               "t2.micro" => "t2.micro"
    key_name:                    "REDACTED" => "REDACTED"
    name:                        "REDACTED" => "<computed>"
    name_prefix:                 "REDACTED" => "REDACTED"
    root_block_device.#:         "0" => "<computed>"
    security_groups.#:           "2" => "2"
    security_groups.1370953371:  "REDACTED" => "REDACTED"
    security_groups.2841519990:  "REDACTED" => "REDACTED"
    user_data:                   "96d90ad7407dade53b36fa86def03628684ef7b6" => "780b94aa343b694846002e4e5d9142b68e54e3c0" (forces new resource)

By the fact that Terraform knows the hash of user_data, it is obvious that all values are known and ready to be baked in. I just can't see what they are, and therefore, the output from my terraform plan is useless to my human eyes.

[llarsson]

Also, I can't reopen issues that a contributor has closed, so I'll just comment here and hope it gets picked up anyway.

[apparentlymart]

Ahh, I see. The problem is that Terraform is showing the user_data value as stored in the state (some sort of hash) rather than the real value that will be submitted to the API.

I think unfortunately that makes this actually more of an issue with the AWS provider, or with the core functionality that renders these diffs, since that hashing would be there even if user_data were _not_ being rendered from a template.

So I'll leave this here as a feature request to show the "real value" that will be written to AWS rather than the hash. Agreed that showing the hash is useless for any human operator; I expect this hashing is mainly just a state file size optimization, so Terraform can detect the change without storing the whole thing.

[nohupped]

I happened to reach here because of a similar requirement.

Well, here's the thing. With my computed values, I still get the following output indicating that Terraform knows what the values should be, but does not want to show any human-readable information about it:

aws_launch_configuration.foo_lc
    associate_public_ip_address: "false" => "false"
    ebs_block_device.#:          "0" => "<computed>"
    ebs_optimized:               "false" => "<computed>"
    enable_monitoring:           "true" => "true"
    iam_instance_profile:        "REDACTED"
    image_id:                    "ami-b3bdffc0" => "ami-b3bdffc0"
    instance_type:               "t2.micro" => "t2.micro"
    key_name:                    "REDACTED" => "REDACTED"
    name:                        "REDACTED" => "<computed>"
    name_prefix:                 "REDACTED" => "REDACTED"
    root_block_device.#:         "0" => "<computed>"
    security_groups.#:           "2" => "2"
    security_groups.1370953371:  "REDACTED" => "REDACTED"
    security_groups.2841519990:  "REDACTED" => "REDACTED"
    user_data:                   "96d90ad7407dade53b36fa86def03628684ef7b6" => "780b94aa343b694846002e4e5d9142b68e54e3c0" (forces new resource)

By the fact that Terraform knows the hash of user_data, it is obvious that all values are known and ready to be baked in. I just can't see what they are, and therefore, the output from my terraform plan is useless to my human eyes.

For now, I just forked the aws provider and made a lame attempt to render the user_data field as a separate optional field (user_data_param_rendered). This is an optional field and is not atomic when using count because of using a global variable, but it still shows the user_data with interpolated values. In our use case, we have user_data that uses many variable interpolations and it was a pain when there is a minor human error that causes the user_data to fail and we had to destroy and recreate it again, and hence I forked it. I mentioned the caveats it in its Readme. Posting it here just in case if it helps someone.

[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.