Feature Request: Verbose option for plan

[gitwitheprogram]

Current Terraform Version

Terraform v0.14.4

Use-cases

Running terraform plan now uses the concise format, which is awesome. Thank you. However, while the output includes lines that inform the user that attributes are hidden, terraform provides no easy way to toggle that output back on.

I confess that it is unlikely that I would use the full plan output often, but it could be helpful for doing a sanity check before certain changes. (for instance, I'm currently working on new modules and importing resources into them, and being able to easily validate that the reason an attribute isn't listed in the plan is because it is already set correctly could be helpful) I'd imagine that this would generally be used a lot more by newer Terraform users than experienced ones.

Attempted Solutions

I could easily write a wrapper script that sets the TF_X_CONCISE_DIFF environment variable to 0, runs terraform plan, and then unsets the variable, but that seems kind of silly to me. Other alternatives to see the settings of the other attributes would include running a terraform state show or pull prior to the plan. Maybe this is what is intended by the Terraform developers?

Proposal

Add a -verbose option to plan to revert to a full plan output.

References

[jgrumboe]

@gitwitheprogram
Sorry, no real answer to this, but at least you don't need to write a wrapper. Just set the value as a prefix to the command in the same line TF_X_CONCISE_DIFF=0 terraform plan. This will set the environment variable just for this one shot.

[gitwitheprogram]

True. However, I wasn't really looking for a better kludge. My point was just that having the -verbose flag here seems like a pretty standard thing. No user is going to know that they can set that environment variable without reading the release notes, as it's not mentioned in the -help output or in the documentation here that I can see.

It seems that the intention was to not provide functionality for users to get the full output, and I was just trying to make a case for it potentially being useful sometimes.

[techdragon]

I recently had a situation where the full output was essential to determining that terraform would do the correct thing before apply.

  # module.<redacted>.aws_security_group.<redacted>-dbs must be replaced
-/+ resource "aws_security_group" "<redacted>-dbs" {
      ~ arn                    = "<redacted>" -> (known after apply)
      ~ description            = "<redacted>" -> (known after apply) # forces replacement
      ~ id                     = "sg-<redacted>" -> (known after apply)
      ~ ingress                = [
          - {
              - cidr_blocks      = [
                  - "10.10.96.0/19",
                  - "10.10.128.0/19",
                  - "10.10.160.0/19",
                ]
              - description      = "Microsoft SQL Server"
              - from_port        = 1433
              - ipv6_cidr_blocks = []
              - prefix_list_ids  = []
              - protocol         = "tcp"
              - security_groups  = []
              - self             = false
              - to_port          = 1433
            },
            # (1 unchanged element hidden)
        ]
      ~ name                   = "<redacted>" -> (known after apply) # forces replacement
      + name_prefix            = (known after apply)
      ~ owner_id               = "<redacted>" -> (known after apply)
        tags                   = {
            "ManagementTool" = "Terraform"
        }
      ~ vpc_id                 = "vpc-<redacted>" -> (known after apply) # forces replacement
        # (2 unchanged attributes hidden)
    }

Looks like its going to purge the ingress from the object for no reason. while with the full output...

  # module.<redacted>.aws_security_group.<redacted>-dbs must be replaced
-/+ resource "aws_security_group" "<redacted>-dbs" {
      ~ arn                    = "<redacted>" -> (known after apply)
      ~ description            = "<redacted>" -> (known after apply) # forces replacement
        egress                 = [
            {
                cidr_blocks      = [
                    "0.0.0.0/0",
                ]
                description      = ""
                from_port        = 0
                ipv6_cidr_blocks = []
                prefix_list_ids  = []
                protocol         = "-1"
                security_groups  = []
                self             = false
                to_port          = 0
            },
        ]
      ~ id                     = "sg-<redacted>" -> (known after apply)
      ~ ingress                = [
            {
                cidr_blocks      = (known after apply)
                description      = "Microsoft SQL Server"
                from_port        = 1433
                ipv6_cidr_blocks = []
                prefix_list_ids  = []
                protocol         = "tcp"
                security_groups  = []
                self             = false
                to_port          = 1433
            },
          - {
              - cidr_blocks      = [
                  - "10.10.96.0/19",
                  - "10.10.128.0/19",
                  - "10.10.160.0/19",
                ]
              - description      = "Microsoft SQL Server"
              - from_port        = 1433
              - ipv6_cidr_blocks = []
              - prefix_list_ids  = []
              - protocol         = "tcp"
              - security_groups  = []
              - self             = false
              - to_port          = 1433
            },
        ]
      ~ name                   = "<redacted>" -> (known after apply) # forces replacement
      + name_prefix            = (known after apply)
      ~ owner_id               = "<redacted>" -> (known after apply)
        revoke_rules_on_delete = false
        tags                   = {
            "ManagementTool" = "Terraform"
        }
      ~ vpc_id                 = "vpc-<redacted>" -> (known after apply) # forces replacement
    }

Makes it clear that terraform doesn't know what the current CIDR block is and that obviously when it applies the state it will perform the value lookup, get the current state (which is what it incorrectly wants to remove), realise its mistake and do nothing. Effectively I have a "phantom update" and the concise output hid this fact from me making it appear that terraform was going to do the wrong thing with no way to confirm it would do the correct thing had I not been able to access the full output without the new concise diff being applied.

I don't care if it stays behind an environment variable, TF_X_CONCISE_DIFF is fine for me, but I understand the current plan is removing this variable and giving us no way to get the full information when performing basic terraform operations (requiring us to muck around with the full JSON output tree to get the full output) is downright distasteful. It screams "we know better than you" and if followed through with will be the first time I come across a decision by the terraform development team that is to me, completely indefensible.

[bomb-on]

It would also be great to add an option to expand n lines of context around the line of interest, e.g. TF_X_DIFF_LINES=2 would show 2 lines above and below the line which would like to be modified, regardless of being part of some block or not.

The use case I had was changing environmental variables for AWS ECS task, which was showing only env var values and not their names, while in the same time showing surrounding blocks for other env vars which were not changing and which were not relevant to this plan at all:

  # aws_ecs_task_definition.this must be replaced
-/+ resource "aws_ecs_task_definition" "this" {
      ~ arn                      = "full_arn" -> (known after apply)
      ~ container_definitions    = jsonencode(
          ~ [
              ~ {
                  ~ environment           = [
                        {
                            name  = "ENVIRONMENTAL_VAR_1"
                            value = "env var 1 value"
                        },
                      ~ {
                          ~ value = "env var 2 value" -> "modified env var 2 value"
                            # (1 unchanged element hidden)
                        },
                        {
                            name  = "ENVIRONMENTAL_VAR_3"
                            value = "evn var 3 value"
                        },
                      ~ {
                          ~ value = "env var 4 value" -> "modified env var 4 value"
                            # (1 unchanged element hidden)
                        },
                        {
                            name  = "ENVIRONMENTAL_VAR_5"
                            value = "env var 5 value"
                        },
                        # (6 unchanged elements hidden)
                    ]
                    # (15 unchanged elements hidden)
                },
            ]
        )
      ~ id                       = "component_id" -> (known after apply)
      ~ revision                 = 6 -> (known after apply)
        tags                     = {
            "environment" = "production"
            # other tags...
        }
        # (7 unchanged attributes hidden)
    }

[soapergem]

Just came across this today for the first time after upgrading to Terraform v0.15.4 and it seems to me that even the TF_X_CONCISE_DIFF env var might be deprecated, as it doesn't seem to do anything...

I just want to echo the concerns of others about not being able to see the full plan. Seeing the full plan is part of the development cycle in some cases. If I'm interacting with some new or convoluted cloud service, I'll sometimes end up creating the resources manually in the console, then crafting my best attempt at a Terraform codification, then import my manually created resources, and finally run a plan to see what I got wrong. This is especially useful as new services come out and when the examples and documentation aren't as fleshed out as they need to be. Concealing the plan just makes everything far more difficult in this case.

[alkar]

Although the concise plan has worked wonders in preserving my sanity since it was introduced, I recently realised while working with aws_cloudfront_distribution that there is a valid case for having a fully verbose plan when working with such resources that have complex internal structures.

Specifically changes made to this resource's ordered_cache_behavior blocks are hard to understand when the context does not include some identifying attribute such as the path_pattern. For example:

[ ... ]
      ~ ordered_cache_behavior {
            # (12 unchanged attributes hidden)

          ~ forwarded_values {
                # (3 unchanged attributes hidden)

              ~ cookies {
                  ~ forward           = "none" -> "all"
                    # (1 unchanged attribute hidden)
                }
            }
        }
[ ... ]

[burner1024]

We need either a more verbose plan, or smarter one, where TF would do a better job at distinguishing repeatable blocks. I think verbose option is simpler?

[chadcarlton]

Looking at the env var, Frankly I am suprised this was taken away.

I am now in a position where terraform says there is a change, but hiding the change, due to the succint diff changes.

What changed on these two resources? They have a change "~" but no sub attributes listed..

Am I safe to apply? At this point I want to revert back to a version of terraform that actually tells me whats going on.

``

  # azurerm_api_management_api.non_prod_dnaapi-person["uat"] has been changed
  ~ resource "azurerm_api_management_api" "non_prod_dnaapi-person" {
        id                    = "/subscriptions/bob/resourceGroups/rg-apim1/providers/Microsoft.ApiManagement/service/apim-non-prod1/apis/uat-dnaapi-person"
        name                  = "uat-dnaapi-person"
        # (13 unchanged attributes hidden)
        # (2 unchanged blocks hidden)
    }
  # azurerm_api_management_api.prod_dnaapi-person has been changed
  ~ resource "azurerm_api_management_api" "prod_dnaapi-person" {
        id                    = "/subscriptions/bob/resourceGroups/rg-apim2/providers/Microsoft.ApiManagement/service/apimg-prod2/apis/prod-dnaapi-person"
        name                  = "prod-dnaapi-person"
        # (13 unchanged attributes hidden)
        # (2 unchanged blocks hidden)
    }

[dduleep]

This really helps when PLAN redirects to an approver who doesn't have access to the real resource.
please enable flag for ”Objects have been changes outside of Terraform” and unchanged blocks hidden new features.

[perobertson]

Is there any way to see the full output now that TF_X_CONCISE_DIFF has been removed?
A flag to specify the number of surrounding lines or attributes would also work here.

For context this is with the ordered_cache_behavior on the aws_cloudfront_distribution that is causing the most issues. When adding in a new cache behaviour you have no context to know if you created the order correctly. The only workaround I have come up with is to apply the change, go check if its correct, and then adjust the code before applying again.

[dduleep]

It is almost 10 months completed, No milestone defined for this bug.

[imaginarynik]

This is terrible! I came here looking for answers and it seems the guys at TF are not listening to the requests!!