Getting "Error with plan:" for (nearly) all modules

[robinbowes]

I have a tree of 89 terragrunt configurations, ie. (terraform.tfvars) files and I'm seeing terragrunt report errors like this for 86/89 of them:

[terragrunt] 2017/12/18 10:31:25 Error with plan: [terragrunt] [/path/to/config/main-account/us-west-2/stages/qa/oauth/eb_env_worker] 2017/12/18 10:30:14 Initializing remote state for the s3 backend

I suspect this is actually two separate lines of output, ie. the two strings that start with [terragrunt]. The first instance comes from line 65 of configstack/stack.go.

I'd do some debugging, etc. but I can't figure out how to build terragrunt locally? (I'll raise another ticket for that).

[robinbowes]

I forgot to add that everything seems to actually work OK, ie. this is a false positive error.

[brikis98]

Any chance you could post more of the output to help debug?

[robinbowes]

There's not a lot to see - just the regular tg/tf output, which is why I want to build a modified version with additional debugging output in configstack/stack.go

[robinbowes]

I've added some debugging statements:

 64     } else if errorStream.Len() > 0 {
 65       terragruntOptions.Logger.Printf("errorStream.Len(): %d\n", errorStream.Len())
 66       terragruntOptions.Logger.Printf("len(output): %d\n", len(output))
 67       terragruntOptions.Logger.Printf("Error with plan:\n== start of output ==\n'%s'== end of output ==\n", output)

and am seeing output like this:

[terragrunt] 2017/12/18 17:01:12 errorStream.Len(): 3350
[terragrunt] 2017/12/18 17:01:12 len(output): 3350
[terragrunt] 2017/12/18 17:01:12 Error with plan:
== start of output ==
[terragrunt] [/Users/robin/Workspace/foo/Terraform/mps-tf-live/main-account/us-west-2/stages/rbtest/backend/eb_env] 2017/12/18 17:00:44 Initializing remote state for the s3 backend
[terragrunt] [/Users/robin/Workspace/foo/Terraform/mps-tf-live/main-account/us-west-2/stages/rbtest/backend/eb_env] 2017/12/18 17:00:44 Running command: terraform init -backend-config=dynamodb_table=terraform-locks -backend-config=region=eu-west-2 -backend-config=encrypt=true -backend-config=bucket=mps-terraform-state-global -backend-config=key=us-west-2/stages/rbtest/backend/eb_env/terraform.tfstate -from-module=file:///Users/robin/Workspace/foo/Terraform/mps-tf-profiles/eb_env /Users/robin/.terragrunt/u0jZXRv-nvMjI4pSiv5WSH6omBU/69qtgL2dc9PmRzryrE94nrpeD6g
Copying configuration from "file:///Users/robin/Workspace/foo/Terraform/mps-tf-profiles/eb_env"...
Terraform initialized in an empty directory!

The directory has no Terraform configuration files. You may begin working
with Terraform immediately by creating Terraform configuration files.
[terragrunt] [/Users/robin/Workspace/foo/Terraform/mps-tf-live/main-account/us-west-2/stages/rbtest/backend/eb_env] 2017/12/18 17:00:44 Initializing remote state for the s3 backend
[terragrunt] [/Users/robin/Workspace/foo/Terraform/mps-tf-live/main-account/us-west-2/stages/rbtest/backend/eb_env] 2017/12/18 17:00:44 Running command: terraform init -backend-config=bucket=mps-terraform-state-global -backend-config=key=us-west-2/stages/rbtest/backend/eb_env/terraform.tfstate -backend-config=dynamodb_table=terraform-locks -backend-config=region=eu-west-2 -backend-config=encrypt=true
Initializing modules...
- module.eb_env
  Getting source "git::git@github.com:intechWiFi/mps-tf-modules.git//eb_env/backend?ref=3.53.0"
- module.label
  Getting source "github.com/cloudposse/terraform-null-label?ref=0.2.0"
- module.eb_env.schedule_trigger
  Getting source "./modules/schedule-trigger"

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "aws" (1.6.0)...
- Downloading plugin for provider "null" (1.0.0)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 1.6"
* provider.null: version = "~> 1.0"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
== end of output ==

It looks to me like there's an error in the logic somewhere.

[robinbowes]

This is terraform v0.11.1, btw.

[brikis98]

I don't see any error there? Terraform may use stderr for log output, which is pretty typical for CLI apps...

[robinbowes]

That's the whole point of this issue - terragrunt is detecting a false positive and writing:

[terragrunt] 2017/12/18 17:01:12 Error with plan:
(lots of output that isn't an error)

[brikis98]

Ohhh, I gotcha.

I'm guessing Terraform 0.11 changed its behavior in terms of what it writes to stdout vs stderr. Terragrunt should be clearly in its log output with this. PR to clean it up is very welcome!

[goodgrits]

Seeing the same issue:

$ terragrunt --version; terraform --version

terragrunt version v0.21.10
Terraform v0.12.16

Directory names altered for modesty:

$ cd /home/<userid>/<tf-workdir>
$ terragrunt plan-all

Line numbers added below to the console output for reference. Note line (4): Error with plan:. This log item is written on any *-all commands, it seems, despite the invocation succeeding:

...(snipped)...
1) Releasing state lock. This may take a few moments...
2) [terragrunt] [/home/<userid>/<tf-workdir>/<myapp1>] 2020/01/27 10:16:37 Module /home/<userid>/<tf-workdir>/<myapp1> has finished successfully!
3) [terragrunt] [/home/<userid>/<tf-workdir>/<myapp2>] 2020/01/27 10:16:37 Module /home/<userid>/<tf-workdir>/<myapp2> has finished successfully!
4) [terragrunt] 2020/01/27 10:16:37 Error with plan: [terragrunt] [/home/<userid>/<tf-workdir>] 2020/01/27 10:16:20 Running command: terraform --version
5) [terragrunt] [/home/<userid>/<tf-workdir>] 2020/01/27 10:16:20 Initializing remote state for the s3 backend
...(snipped)...

If I execute the singular version of a command (ex: plan, apply, etc.) against any particular child module (say, for <mayapp1> or <myapp2>), those invocations complete successfully as well without the Error with plan: log item.

Another observation is that line (4) seems to have two log entries. The Error with plan log item does not end with a newline -- there is another log item (Running command: terraform --version in this case) immediately following. Just struck me as curious.

[JoshuaSeidel]

I am seeing this as well. Can this get looked at. looks like a issue from 2017. its 2020...

[scottb-isp]

I'm observing this as well. There are no errors in my output but the final message indicates there are errors

[terragrunt] 2020/02/25 11:35:15 Error with plan: [terragrunt] [c:\projects\sandbox\tf-and-tg\aws-accounts\Dev\us-west-2\dev\app_faux_2] 2020/02/25 11:35:03 Running command: terraform --version

$>tg -v
terragrunt version v0.22.4
$>tf -v
Terraform v0.12.21

There are no ERRORS, Errors, errors, or eRRors, in the output of my plan above that final message.

[lukasz-kaniowski]

did anyone figured out what may be the issue here, I'm seeing same problem now

terragrunt version v0.23.2
Terraform v0.12.23

[yorinasub17]

This is a known issue with the error reporting of terragrunt. There is an open PR that attempts to fix this, but has not received any updates: #722 .

[kaka-ruto]

Having the same issue.

[ahmad-hamade]

I'm facing the same issue too

[kaka-ruto]

@ahmad-hamade , try running each module singly. You might get a more descriptive error that can be easy to fix. Did it this way and it helped.

[ahmad-hamade]

@kaka-ruto I tried this already and never got this error.

[tokiwong]

Also receiving this error/false positive, where going into individual modules report no errors with the plan, but trying to do an apply-all ultimately fails unless I use the flag --terragrunt-ignore-dependency-errors which doesn't actually solve the root of the problem

[kaka-ruto]

Mine may not be a comprehensive answer and I do wish I was skilled enough to improve the error message this awesome tool provides.

What I managed to do, was to run a single module, then follow my logs line by line and see at which point the process was failing. At most times it was a syntax error or I was using an AWS region for a service that isn't supported in that region yet.

At other times it was that I needed to run another module first (dependencies), before running the current module. It was a little trial and error but yeah, hope it helps somewhere.

[alexkayabula]

@robinbowes @kaka-ruto @tokiwong @lukasz-kaniowski @JoshuaSeidel , I presume this PR should have resolved this issue.

[brikis98]

@alexkayabula's PR in #1229 was released in https://github.com/gruntwork-io/terragrunt/releases/tag/v0.23.28. That hopefully fixes this issue. Try it out and let us know!

[tokiwong]

@brikis98 lgtm, thanks!

[ChristophShyper]

Can't test it now, but so happy this issue was addressed :) Finally no need to explain everybody new to Terragrunt it's a feature ;)