Add a print block to Terraform HCL

[gregbaleyy]

Terraform Version

1.9.0

Use Cases

When having multiple module and submodules layers, it becomes a burden to debug the value of a variable or a local.
Instead of using multiple chained output blocks, print block would directly output a value to stdout for human to read.

Attempted Solutions

Sometimes I need to debug the value of a variable or a local of a sub-sub-module. The only way I found so far is to create an output at each level referencing the ouput of the level below. It works fine but it is a heavy and error prone process. Also I think of it as a misuse of output block as I am only checking the output value to debug my code and not to expose some value to the caller module.
This workaround works fine but it could be improved.

Proposal

A good way to solve this would be to implement a print block on the same model of the output block in the module where the variable or local is set.

print "example" {
  description = "value set in my module"
  value       = local.example
}

This print block would only produce stdout print at the end of the terraform plan and could not be queried by any other module. It is just a print for human.
Because it prints directly to stdout, you don't need to repeat the print block on each level of your module hierarchy.

References

No response

[gesnaud]

Nice to have!

I could be only agree about heavy output that makes too much noise in our code for... nothing but debugging.

[apparentlymart]

Thanks for this feature request, @gregbaleyy.

I wasn't able to find it quickly to link to it, but I remember that there's another issue somewhere suggesting a variation of this that's driven from the command line instead of from configuration.

I don't remember exactly what was proposed but it was something to the effect of:

terraform plan -trace=local.example

My mental model of how this would work is that each time Terraform visits and evaluates the value of the given object, the UI would check whether its value changed since last time (for example, switching from unknown to known during the apply phase) and would describe that using an extra item in the progress messages.

That model might work better for one-off debugging where the need to view a particular value is temporary, but it does seem to need some special new syntax to deal with the situation where the object to be traced is in a module other than the root module, since we don't currently have any reference expression syntax that can cross module boundaries. (The "Resource Address" syntax used for moved blocks and -target arguments is partially that, but isn't general enough to refer to items such as local values.)

Doing it in the configuration might avoid the need for a new "absolute expression" syntax, but I also have a feeling that even if we did implement it for configuration we'd quickly have folks requesting something one-off on the command line (or similar) anyway, just because that's the more convenient option for one-off debugging. 🤔

FWIW I did once try to implement something like what I described above and it seemed plausible but was too invasive a change for me to make without some further discussion. I expect the branch I was working on is still around somewhere and probably associated with the original issue, so if we can find the original issue we might be able to track it down. (It was quite some years ago now, unfortunately.)

[gregbaleyy]

Thank you @apparentlymart for your detailed feedback !

I agree, having a command line option would be difficult to use because of the address of the resource to print out.

But a command line option could be a good idea in combination with the configuration block to toggle print to stdout. It would be a kind of "debug verbose" on the configuration level (distinct from the terraform debug mode with TF_LOG). The risk would be to create many of these print block everywhere as dormant configuration living there forever. Which would be a challenge when going at scale, because print mode would output so much information to stdout (from the print blocks of every submodules). Filtering this out would lead us back to the problem of resource addresses... Or you would need a way to redirect to JSON for later filtering.