What is -concise supposed to do?

[giner]

I was looking for a concise output from OpenTofu just to get a summary on what's about to change, something like this

create: xxx1
create: xxx2
read: yyy1
read: yyy2
replace: zzz1
replace: zzz2
...

I used to run the following

tofu plan --json | jq -sr '[.[] | select(.type == "planned_change") | .change] | sort_by(.resource.addr) | sort_by(.action) | .[] | .action + ": " + .resource.addr'`

but was hoping for a built-in option so I've found #306 which mentioned -concise. I've found this gif which looks very similar to what I was looking for hover running the latest version of open tofu doesn't show any difference when I add -concise to the plan command

tofu plan

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # local_file.test will be created
  + resource "local_file" "test" {
      + content              = "Hello, World!"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "/tmp/test"
      + id                   = (known after apply)
    }

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

tofu plan -concise

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # local_file.test will be created
  + resource "local_file" "test" {
      + content              = "Hello, World!"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "/tmp/test"
      + id                   = (known after apply)
    }

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

Does -concise work? What is it supposed to do?

Btw, double dash (--) doesn't work for this particular command while for most other commands it works (using a single dash is a bit scary because normally -abc is translated as multiple options -a, -b and -c by other unix/linux commands).

[abstractionfactory]

Hi @giner the -concise flag was introduduced in #1225 and is intended to shorten the plan output. Unfortunately, it is one of the features where everyone seems to have different needs (see #2409) and we can't possibly make it right by everyone.

The flag itself omits the "refreshing state" entries from the output when planning, which was unnecessary noise for many. In your case there may be no such logs because you are using local_file, which is done instantly.

[giner]

I see, thank you @abstractionfactory. Then the problem of concise (brief, summary, whatever we call it) output for manual run is yet to be solved. While we can come up with whatever tooling and wrappers for CI as we do this once, for using external tools is very inconvenient for local/manual runs.

[abstractionfactory]

The main issue with this feature is that everyone is expecting a different outcome. Based on the conversations we had around #2409 with the core team, I'd say we are rather unlikely to entertain the idea of accepting issues in this area unless there is broad support for a narrowly tailored change, or we run the risk of an avalanche of issues from people who want their output presented differently. For the time being, I believe external tools are the way to go, just as, for example, the Go ecosystem has a host of tools parsing their test output and presenting it in a human-readable form.

[giner]

I see what you mean and I agree, it probably makes sense to get the community consensus before moving forward in any direction.

At the same time I believe that two distinct issues got mixed up here:

• Output suitable for automation (including CI)
• Summary/brief output for an operator just to catch the changes at glance before digging in to the detailed output

I'm personally not very much interested in the first one as it can be solved multiple ways even now. However the second one should be a significant improvement for anyone running terraform manually. Shouldn't this be discussed separately?

[abstractionfactory]

So, for CI output the ideal way to work around this would be using the JSON output and then converting it into a format that the particular CI system requires. For example, GitHub Actions needs this formatting whereas GitLab needs this format. We could add this formatting all to OpenTofu, but OpenTofu releases infrequently compared to smaller tools that can release updates and fixes very quickly.

Regarding the summary, the output needs to be verbose enough for an operator to clearly observe what changes will be made to the infrastructure. I believe it is very intentional that an operator should review all the changes and not just LGTM a summary. If you would like to open an issue to that end, that can be discussed, but I would recommend making the changes very specific as to what to hide in particular, otherwise the discussion will get side-tracked with everyone wanting a different set of outputs.

[giner]

I'm leaving this comment here for the future if I am or somebody else decides to open another ticket on this.

---

For CI part this all makes sense to me. At the same time it's not me who needs it.

I believe it is very intentional that an operator should review all the changes and not just LGTM a summary

On the one hand it's true, it's usually the whole change needs to be reviewed in details (not always though, especially with deletions or well-known repeated changes), on the other hand it's easy for something important to split through in a big change. The summary would give a quick look on what resources are touched and in what way (added, updated, deleted, recreated). Right now terraform plan/apply shows a large diff plus very short summary (x to add, y to change, z to destroy). While this summary is already helpful (we can easily spot something being destroyed when we don't expected it) it shows too little information to be really useful.

In short the suggested change would look something like below (here is a gif posted by @flavono123 on #306 (comment) which shows a similar idea done by some wrapper).

Without --summary flag (i.e. the current current default behavior):

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # local_file.test will be created
  + resource "local_file" "test" {
      + content              = "Hello, World!"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "/tmp/test"
      + id                   = (known after apply)
    }

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

With --summary flag

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # local_file.test will be created
  + resource "local_file" "test" {
      + content              = "Hello, World!"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "/tmp/test"
      + id                   = (known after apply)
    }

Summary:
create: local_file.test

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