Terraform: concise mode for `terraform plan`

[spkane]

Feature request

Add a concise mode to terraform plan.

Sometimes simple things like updating a large cloud-init template, can make the output of terraform plan hard to read through.

It would be very nice to have something like a --concise switch that would only show the change header lines and the final summary like:

-/+ module.ec2_master.template_file.cloudinit_master.3
~ module.ec2_agent.aws_elb.ext_http_proxy_lb

Plan: 1 to add, 1 to change, 1 to destroy.

[mitchellh]

Tagged as enhancement. For future: I'd say the flag should be -short.

[spkane]

Basically something close to this output:

tf plan -no-color | grep -E '^[[:punct:]]|Plan'

[stephenchu]

I know that PR #10649 is already out there, but I would also love to eliminate the following general explanation/description text from plan.

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.

I sense that the functionality I'm after should not be part of -short tho, so maybe -quiet.

[apparentlymart]

Given that there are lots of parts of the terraform plan output that people are likely to want to opt out of separately, perhaps it behooves us to use more descriptive names, at the expense of them being longer, so that their meaning is clearer (vs. something non-obvious like terraform plan -short -quiet):

• --show-attrs=false to hide the resource attributes from the diff, getting the behavior @spkane wanted
• --show-usage-help=false to hide the paragraphs of text intended to help explain Terraform's workflow, as @stephenchu wants

Both would default to true, preserving today's behavior.

[josephholsten]

Well, shoot. I tried rebasing #10649 today and command/plan.go has been significantly changed to use backend.

Currently, the actual checks for the show flag have to be made in backend/local/backend_plan.go. Unfortunately, it's not entirely clear how to get the show (or show-attrs & show-usage-help) from command/plan.go:(*PlanCommand).Run() over to backend/local/backend_plan.go:(*Local).opPlan() to make those checks.

Some nearby calls currently:

• b.CLI.Output(): github.com/mitchellh/cli.Ui.Output(). This isn't that common of a problem to solve at that level.
• b.Colorize(): colorstring.Colorize I guess we could add a filtering function, but then every print will require many filter passes. It already hurts now: b.CLI.Output(b.Colorize().Color(fmt.Sprintf(. And we don't need to track state like a colorizer.
• b.ContextOpts: *terraform.ContextOpts`: haha, no.
• ctx: context.Context always has Value(). ugh.
• op: backend.Operation: we could add ShowAttrs bool and ShowUsageHelp bool, I guess?

It's too bad we don't have a JSON format for plans, because then we could just throw jq at it.

[josephholsten]

oh, and to pitch into the flag sprawl, another display flag proposal for terraform plan -diff is at https://github.com/hashicorp/terraform/pull/11081 Kinda sounds like --show-usage-help=false.

[apparentlymart]

Hi all,

There have been a few different requests for variants of the plan output recently. I wanted to respond to that, but since there isn't a single central place I guess I will respond here for now:

At the current point in Terraform's development, we're being rather cautious about adding lots of options -- particularly CLI options, but also flags set in configuration -- because they significantly increase the testing surface and make it hard to do the internal refactoring we're still doing a lot of as we figure out the details of Terraform's architecture. We've found in earlier work that the non-default cases inevitably get short shrift when big changes are made, or that testing and supporting them ends up being a significant part of the development process.

Therefore I'm going to ask for some patience on features for UI and workflow customization, such as this request. In the long run we'd like to make Terraform's output flexible to serve lots of different cases, but that'll be easier to accomplish as the core architecture starts to stabilize and we can afford to make more assumptions.

Thanks for the great discussion here. This will be helpful as we review use-cases in future, when we get to the point of refining the UI details in this area.

[Samangan]

Hey, I think this viewpoint makes perfect sense. At this point, the amount of complexity added supporting these types of features would probably outweigh any benefits they bring. I'm going to close my PR.

[cheptsov]

One of the things I struggle with is that when doing terraform plan, it outputs the actual content of s3 objects being modifies. With pretty large binary files being uploaded, the output takes MBs and then is very hard to read and sometimes even not possible at all.

[rverma-nikiai]

@apparentlymart It's being a long time, wondering if we can start accepting pull requests like this. I think we are well aware of the requirement for this kind of pull requests. Terraform being in a position to support automation, this kind of defies the purpose. If we can't understand what terraform is actually doing cause of all such noise, it becomes very challenging to handle huge projects.

Created another issue related to this but we can track all progress here.
https://github.com/hashicorp/terraform/issues/20960

[ketzacoatl]

@rverma-nikiai https://github.com/coinbase/terraform-landscape ought to hold you over in the meantime ;)

[rverma-nikiai]

@ketzacoatl I doubt it serves the purpose. I am more interested in hiding too verbose information in terraform output. This looks can make terraform messages more human readable.

[pijemcolu]

I'm a fan of:
terraform plan | grep -E '#'

[kunickiaj]

Found this one works well for me: terraform plan | grep -E '^\s*[#~+-]'

[ewillia1983]

I had to add the -no-color flag --
terraform plan -no-color | grep -E '^.*[#~+-] .*'

[chattr]

This is a nice hybrid of above suggestions:
terraform plan -no-color | grep -E '(^.*[#~+-] .*|^[[:punct:]]|Plan)'

[Tbohunek]

Given that there are lots of parts of the terraform plan output that people are likely to want to opt out of separately, perhaps it behooves us to use more descriptive names, at the expense of them being longer, so that their meaning is clearer (vs. something non-obvious like terraform plan -short -quiet):

• --show-attrs=false to hide the resource attributes from the diff, getting the behavior @spkane wanted
• --show-usage-help=false to hide the paragraphs of text intended to help explain Terraform's workflow, as @stephenchu wants

Both would default to true, preserving today's behavior.

For every "long" parameter, please also include equivalent shortcut or allow saving this into an env variable. Just imagine typing those two above parameters every time.

[Tbohunek]

When changing plan output, maybe you could also include this? https://github.com/hashicorp/terraform/issues/24233
To have number of replaced resources at the end of the output.

[byarbrough]

Totally hear what @apparentlymart is saying. When it is time to have the discussion, it would be great to have a short option that can be ingested into CI/CD pipelines.

As an example, GitLab 13.0 will embed a "create, update, delete" summary in merge requests !26830. This makes it easy for reviewers to see what changes will be made to infrastructure if they approve the request.

However, in order to make this work, the current solution is to pipe show -json output into a nasty jq query. This would certainly be simpler with some sort of summarized output from show, and I think improving interface with CI/CD pipelines is among one of the best reasons to have this enhancement.

_Edit: here is the just published GitLab documentation: https://docs.gitlab.com/ee/user/infrastructure/#output-terraform-plan-information-into-a-merge-request_

[sidcarter]

over 2 and a half years since @apparentlymart 's original response. Is this something that is being considered now, that it's 0.13 and this would be really helpful in terms of automation.

[mwarkentin]

@sidcarter good timing! https://github.com/hashicorp/terraform/releases/tag/v0.14.0-alpha20200910

[severity1]

with terraform cloud and its tiny output review box it's a bit too much to scroll 2000 lines of output when inspecting the plan output for a single change that spans multiple resources - like tags, I know it's just tag changes in this example but you still will want to inspect all the changes because there might be other changes outside your actual Pull Request.

EDIT: Nice to know that Concise diff will be default from 0.14.x onwards. Looking forward to this version!