Compatibility with Terraform Cloud's "Remote" execution mode

[nikolay]

It is sad that tfautomv does not work with TFC.

[busser]

Thanks for reporting this issue!

Currently running tfautomv in a workspace backed by Terraform Cloud returns the following error:

Running "terraform init"...
Running "terraform plan"...
╷
│ Error:
│
│ Command "/Users/arthur/.local/bin/terraform" with args ["terraform" "plan" "-out" "/var/folders/pd/5hzr27_n6rq2qzr14mdlf8nh0000gn/T/tfautomv.3778480672.plan"] failed: exit status 1
│ Command output:
│ ╷
│ │ Error: Saving a generated plan is currently not supported
│ │
│ │ Terraform Cloud does not support saving the generated execution plan
│ │ locally at this time.
│ ╵
│
╵

After doing a little digging, I found that this issue only impacts workspaces with the "Remote" execution mode. Workspaces with the "Local" execution mode work just fine.

You can change a workspace's execution mode in the workspace's settings, but that may not be suitable for your needs.

[busser]

In order to determine which moves to make, tfautomv currently uses the raw data in Terraform's plan. Without access to that data, I am not sure how we could determine which moves to make.

All ideas are welcome 🙂

[busser]

I've added a test for this, which reproduces the steps I followed to obtain the error above, in PR #18.

[wintergren]

Supporting TFC workspaces with remote executions would be nice. While changing to local execution does work it also requires us to create a local tfvars file with any variables set in the workspace.

Would it be possible to support it by doing something like this? terraform plan -no-color 2>&1 | tee plan.txt

That way it's possible to store the plan locally even for remote executable workspaces, so could tfautomv use that for this case?

[busser]

Sadly that would not work.

Terraform has different formats in which it can display its plan:

1. The human-readable output of terraform plan
2. The machine-readable output of terraform plan -out tfplan.bin followed by terraform show -json tfplan.bin

The machine-readable plan has much more information that the human-readable one, which is why tfautomv uses that one. The human-readable plan is also difficult to parse and its format can change from one release to another, so reading it from a program is not recommended.

The problem we face is that terraform plan -out tfplan.bin does not work with remote execution on Terraform Cloud. Or at least not yet.

This issue (https://github.com/hashicorp/terraform/issues/32138) mentions this limitation. The solution suggested by @apparentlymart would solve the problem for us, because terraform show -json tfplan.bin would then produce the rich machine-readable plan that tfautomv needs.

Until that is implemented however, I do not have any workaround that works out of the box for workspaces with remote execution.

If you have any other suggestions, I am happy to discuss them :)

[busser]

This issue is resolved as of Terraform v1.6 🎉

As of v1.6, Terraform supports the -out flag for remote runs on Terraform Cloud, which is what tfautomv needs to perform its analysis.

[wintergren]

Hmm, really? I updated TFC workspace to v1.6.3 and tfautomv to latest version. I still get the following error:

Running "terraform plan"...
╷
│ Error:
│
│ exit status 1
│
│ Error: Saving a generated plan is currently not supported
│
│ Terraform Cloud does not support saving the generated execution plan locally
│ at this time.
│```

[busser]

Weird, it worked on my end. Did you also upgrade the Terraform CLI on your workstation to 1.6?

[wintergren]

That's true, I homebrew upgraded terraform but that only took it to 1.5.7 Had to upgrade hashicorp/tap/terraform instead to get 1.6.3

But now I instead get this error running tfautomv, on the init:

Running "terraform init"...
╷
│ Error:
│
│ exit status 1
│
│ Error: Invalid workspaces configuration
│
│ Specified workspace "name" conflicts with TF_WORKSPACE environment variable.
│
│ The 'workspaces' block configures how Terraform CLI maps its workspaces for
│ this single
│ configuration to workspaces within a Terraform Cloud organization. Two
│ strategies are available:
│
│ tags - A set of tags used to select remote Terraform Cloud
│ workspaces to be used for this single
│ configuration. New workspaces will automatically be tagged with these tag
│ values. Generally, this
│ is the primary and recommended strategy to use.  This option conflicts with
│ "name".
│
│ name - The name of a single Terraform Cloud workspace to be used
│ with this configuration.
│ When configured, only the specified workspace can be used. This option
│ conflicts with "tags"
│ and with the TF_WORKSPACE environment variable.
│
│
╵

Conf looks like this:

        terraform {
          cloud {
            hostname     = "app.terraform.io"
            organization = "org-name"

            workspaces {
              name = "example-workspace-name"
            }
          }
        }

[busser]

I did some digging and found the problem. There was a bug in a library that tfautomv uses. I had already upgraded to a newer version of the library where the bug was fixed, but I hadn't released a version of tfautomv that included that update.

Version 0.5.4 of tfautomv now works with Terraform Cloud backends with remote execution!

To make sure, I added an automated test that makes sure tfautomv works as expected with Terraform Cloud.

Please upgrade to v0.5.4 and let me know if it works :)

[wintergren]

Awesome! Tested 0.5.4 and can verify it indeed works! Thanks alot 👍 This will save much time. It does not identify all moves, but even finding maybe 60% is a major win.

[busser]

Great!

Future versions of tfautomv will add enhancements to move-finding logic. If you have any ideas for improvements or examples cases where tfautomv fails, please open issues. The more info we have, the better the tool will get!

Marking this issue as resolved.