Open mcandre opened 3 years ago
How do I 'up-vote' ?
also, offer a 'clean' mode "-s" or "simple" that does not "pretty print" and outputs only plain text.
or: --no-pretty
From the lets-make-it-complicated-department, having an in-resource way to control the verbosity would be nice. For some resources, it's normal(ish) for them to take a long time to provision, so getting "still working" messages so often is distracting and unhelpful, but for other resources, where normal provisioning is fast, seeing that it is slow is may give an operator a hint that something is going wrong elsewhere.
In the even-more-complicated-department, if terraform would expose prometheus metrics, I'd scrape 'em during CI.
It would be great having a quiet flag for suppressing the reading data/refreshing state output info like we had with refresh=false
until terraform 1.2.x.
Specific use case this would resolve: we often have to "diff" a large number of terraform modules (e.g. when modifying a module other modules depend on). With the current "terraform plan" verbosity, it is quite hard to understand whether there is actually any diff and what they are. -detailed-exitcode helps a bit but scrolling up through endless debug output is still a pain to understand what the diffs are. It would be much nicer if "terraform plan" could print only diff on stdout. Anything else could either be not printed or printed on stderr where it's easy to filter out.
Current Terraform Version
Use-cases
Reduce the I/O noise of a typical Terraform run.
Attempted Solutions
Ansible is often quieter than Terraform, however the Ansible Galaxy playbooks may not always be as well maintained as Terraform modules.
Proposal
Offer a
-quiet
flag that skips the great mass of "Still creating...", "Still destroying..." messages that Terraform spits out.Let's try harder to follow UNIX conventions, so that our tools run essentially silently, and only talk when explicitly asked or in the event of an error. DevOps tools in the Go world tend to follow this convention as well.
When working locally, this issue is more cosmetic. It's about how the noise distracts from higher level activities.
When working remotely, the I/O waste actually costs more to operate, in terms of transmission and storage fees.
At the very least, let's trim down the async in-progress noise. There isn't any actual information in these extra messages that the normal "Creating...", "Creation complete" doesn't already convey. So trimming down the extraneous messages is not only easier to read, but also greener in terms of electricity usage.