Terragrunt: Make it possible to use modules from Terraform Registry

[antonbabenko]

Correct me if I am wrong, but it is not possible to download modules from Terraform Registry.

terragrunt = {
  terraform {
    source = "terraform-aws-modules/ec2-instance/aws"
  }
}

Error

Copying configuration from "file:///tmp/terragrunt-infrastructure-live-example/non-prod/us-east-1/qa/mysql/terraform-aws-modules/ec2-instance/aws"...
Error copying source module: error downloading 'file:///tmp/terragrunt-infrastructure-live-example/non-prod/us-east-1/qa/mysql/terraform-aws-modules/ec2-instance/aws': source path error: stat /tmp/terragrunt-infrastructure-live-example/non-prod/us-east-1/qa/mysql/terraform-aws-modules/ec2-instance/aws: no such file or directory

terragrunt version v0.13.7

[brikis98]

We use terraform init (with the -from-module param) under the hood to download modules, so if that doesn't work, you should probably file the bug with the Terraform repo itself.

[antonbabenko]

-from-module parameter is composed incorrectly before it is passed to terraform init, and, yes it is not supported in Terraform.

When using git as a source, it is set to:

-from-module=git::ssh://[email protected]/gruntwork-io/terragrunt-infrastructure-modules-example.git?ref=v0.0.1

When using local directory as well as terraform registry:

-from-module=file:///tmp/terragrunt-infrastructure-live-example/non-prod/us-east-1/qa/mysql/terraform-aws-modules/ec2-instance/aws

Terraform understands if a directory is not present then it looks into the Terraform registry. Similar logic has to be implemented in Terragrunt when creating -from-module argument once Terraform has support for registry sources I think.

[antonbabenko]

How to use Terragrunt with Terraform Registry modules without rewriting them to git URLs?

[brikis98]

-from-module parameter is composed incorrectly before it is passed to terraform init,

We use HashiCorp's go-getter library to format URLs. Maybe the newer version supports registry URLs?

How to use Terragrunt with Terraform Registry modules without rewriting them to git URLs?

No way to do so now AFAIK

[antonbabenko]

AFAIK Terraform 0.11 will have better support for the registry, and for now, I will use git URLs. Thank you!

[ghost]

How can you use git urls to the registry modules when those modules don't include the

terraform {
  backend "s3" {}
}

provider "aws" {
  region = "${var.region}"
}

parts that are necessary to use a module within terragrunt?

I tried defining a module in my modules repo, but that doesn't seem to work. I have prod/vpc/main.tf which looks like this:

terraform {
  backend "s3" {}
}

provider "aws" {
  region = "${var.region}"
}

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "${var.name}"

  cidr = "${var.cidr}"

  azs                 = ["${var.azs}"]
  private_subnets     = ["${var.private_subnets}"]
  public_subnets      = ["${var.public_subnets}"]
  database_subnets    = ["${var.database_subnets}"]
  elasticache_subnets = ["${var.elasticache_subnets}"]

  create_database_subnet_group = "${var.create_database_subnet_group}"

  enable_nat_gateway = "${var.enable_nat_gateway}"

  enable_s3_endpoint       = "${var.enable_s3_endpoint}"
  enable_dynamodb_endpoint = "${var.enable_dynamodb_endpoint}"
} 

But when I try to do any terragrunt commands, it blows up with errors. So it seems like there is no way to use the module repository with terragrunt? Doesn't that pretty much defeat the purpose of terragrunt and its emphasis on DRY when I have to completely duplicate the code in a repository module in my own module in order to use terragrunt?

[antonbabenko]

@sgendler-stem I have just published the minimalistic code I use for this: https://gist.github.com/antonbabenko/2ca1225589c7c6d42f476f97d779d4ff

[brikis98]

But when I try to do any terragrunt commands, it blows up with errors.

What errors?

[antonbabenko]

The error @sgendler-stem is referring to was probably related to file named main.tf which is overwritten with the one you provide, but this is just a guess. :)

[brikis98]

to file named main.tf which is overwritten with the one you provide

What do you mean? Terragrunt doesn't "provide" any main.tf files...

[antonbabenko]

It is not a problem of Terragrunt, but how files are named in main.tf (prod/vpc/main.tf) and the one provided by Terraform VPC module. Point 2

[brikis98]

Sorry, still not entirely following. Are you saying that @sgendler-stem has a main.tf file in the local folder that includes terraform-aws-modules/vpc/aws as a module and a terraform.tfvars file that sets the source param also to terraform-aws-modules/vpc/aws?

If so, then yes, one of the main.tf files would override the other. The solution, of course, is to either (a) put the local main.tf file into a separate folder/repo and point the source param in terraform.tfvars to that folder/repo or (b) not use Terragrunt at all and just directly run init, plan, and apply on the local main.tf.

[ghost]

I'm not certain I understand the fix yet, as I haven't played with it yet,
but Anton is correct that I have a prod/vpc directory in my 'modules' repo
(we need a better vocabulary to differentiate between actual terraform
modules and a subdirectory in the live repo for terragrunt) which contains
a main.tf that then calls out to a module called vpc which also includes a
main.tf. If I'm understanding the comment stream here, I guess
terragrunt/terraform is pulling everything into a single directory
structure somewhere and one vpc/main.tf file is overwriting the other
rather than co-existing with it. That's an easy enough fix to make on my
end, but definitely worth documenting somewhere in the terragrunt docs, as
I can only imagine that naming a directory in the modules repo after the
module that it uses to do work is a reasonably common pattern and the error
messaging around it isn't very clear. It'd be fantastic if terragrunt
could detect the name conflict and rename one of the files, but even just
providing an explicit error message would short circuit a lot of the trial
and error experimentation I ended up doing to try to fix it.

In the meantime, I just reached out about getting access to the IAC library
via gruntwork's website. We may go with the reference architecture, too,
since it doesn't have to save me much time to be cost effective, but I
figure the library code will help me determine if I need it. We were
wanting to migrate to kubernetes from ECS and we do use elasticsearch,
neither of which are currently supported by your architecture, so we'll
have some development pain or costs, regardless. The actual operating
environments for our app are standard enough to be easy to implement. It's
things like the devops VPC with VPN access and connections to all other
environments, and a fully functional CI/CD pipeline which are more complex
and time-consuming to automate. Getting some best practices guidance on
things like secrets management would also be really helpful.

On Tue, Oct 31, 2017 at 4:45 AM, Yevgeniy Brikman [e-mail]
wrote:

Sorry, still not entirely following. Are you saying that @sgendler-stem
https://github.com/sgendler-stem has a main.tf file in the local folder
that includes terraform-aws-modules/vpc/aws as a module and a
terraform.tfvars file that sets the source param also to
terraform-aws-modules/vpc/aws?

If so, then yes, one of the main.tf files would override the other. The
solution, of course, is to either (a) put the local main.tf file into a
separate folder/repo and point the source param in terraform.tfvars to
that folder/repo or (b) not use Terragrunt at all and just directly run
init, plan, and apply on the local main.tf.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-340738281,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqJLbBWE4MLwA2cnH2H-lgu5FJ6piks5sxwhugaJpZM4PxXd4
.

[brikis98]

If I'm understanding the comment stream here, I guess terragrunt/terraform is pulling everything into a single directory structure somewhere and one vpc/main.tf file is overwriting the other rather than co-existing with it.

That depends on how you have Terragrunt configured. What does your terraform.tfvars file contain? What is your directory structure?

It's things like the devops VPC with VPN access and connections to all other environments, and a fully functional CI/CD pipeline which are more complex and time-consuming to automate.

The IAC library has code to set up VPCs, OpenVPN, and Jenkins, which will save you a bunch of time, but it's the Ref Arch that ties all those pieces together into an end-to-end solution, which is also a big time saver. Whether the Ref Arch make sense for you depends on your needs, so feel free to email me if you want more info!

[ghost]

In my live repo, I have

live-repo/
terraform.tfvars:

terragrunt = {
terraform {
extra_arguments "retry_lock" {
commands = ["${get_terraform_commands_that_need_locking()}"]
arguments = ["-lock-timeout=20m"]
}
}
remote_state {
backend = "s3"
config {
bucket = "stem-terraform-state-us-west-2"
key = "${path_relative_to_include()}/terraform.tfstate"
region = "us-west-2"
encrypt = true
dynamodb_table = "terraform-lock-table"
}
}
}

prod/
vpc/
terraform.tfvars:

terragrunt = {
terraform {
source = "git::ssh://
[email protected]/stems/stem-infra.git//vpc?ref=refs/heads/master"
}
include {
path = "${find_in_parent_folders()}"
}
}

name = "prod"
region = "us-west-2"
cidr = "10.0.0.0/16"
azs = ["us-west-2a", "us-west-2b", "us-west-2c"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnets = ["10.0.11.0/24", "10.0.12.0/24", "10.0.13.0/24"]
database_subnets = ["10.0.21.0/24", "10.0.22.0/24", "10.0.23.0/24"]
elasticache_subnets = ["10.0.31.0/24", "10.0.32.0/24", "10.0.33.0/24"]
create_database_subnet_group = true
enable_nat_gateway = true
enable_s3_endpoint = true
enable_dynamodb_endpoint = false
enable_dns_hostnames = true
enable_dns_support = true

Then in my modules repo, I have the following:

modules-repo/
vpc/
main.tf:

terraform {
backend "s3" {}
}

provider "aws" {
region = "${var.region}"
}

And then I had something like

module "vpc" {
source = path/to/vpc/module

var1 = "${var.var1}"
var2 = "${var.var2}"
... and many more variables all copied straight through
}

With a variables.tf file copied straight from the module in question, and
an outputs.tf file which was nearly identical to the outputs.tf from the
module, but with the output value prepended with "module.vpc."

It was a lot of typing to set up and seemed like the antithesis of DRY -
have to modify local variables.tf and outputs.tf to match every change to
the remote version in the module registry, and have to copy variables
through manually. But then it didn't work, anyway, due to the file name
conflict.

It still isn't clear that I wouldn't have all of that copying to do.
Anton's example didn't include it, but it wasn't clear that it was correct,
either, since the terraform.tfvars file pointed directly to the module
source, not to my local module repo, where the renamed main.tf file would
be located. I haven't had a chance to experiment with it, yet.

On Tue, Oct 31, 2017 at 11:30 AM, Yevgeniy Brikman <[email protected]

wrote:

If I'm understanding the comment stream here, I guess terragrunt/terraform
is pulling everything into a single directory structure somewhere and one
vpc/main.tf file is overwriting the other rather than co-existing with it.

That depends on how you have Terragrunt configured. What does your
terraform.tfvars file contain? What is your directory structure?

It's things like the devops VPC with VPN access and connections to all
other environments, and a fully functional CI/CD pipeline which are more
complex and time-consuming to automate.

The IAC library has code to set up VPCs, OpenVPN, and Jenkins, which will
save you a bunch of time, but it's the Ref Arch that ties all those pieces
together into an end-to-end solution, which is also a big time saver.
Whether the Ref Arch make sense for you depends on your needs, so feel free
to email me if you want more info!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-340859312,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqFitCZy-31FEUKKpq0vWUHJQUq4Zks5sx2dhgaJpZM4PxXd4
.

[brikis98]

But then it didn't work, anyway, due to the file name conflict.

Based on your usage, I don't see how there could be a file name conflict. Terragrunt will download the module from your vpc-modules repo into a tmp folder. It will then call terraform init on it, which should result in the VPC module being downloaded from the Terraform registry into a .terraform folder within the tmp folder.

Could you paste the log output from running Terragrunt?

[ghost]

I will if I run into it again. I just got access to the gruntworks library
so I’m going to dig into that. If I have more problems, I’ll let you know,
but until I’ve tried some of these suggestions, I don’t want to waste
anyone’s time since I don’t have code that looks like that right now, so I
have no way to validate what I’m saying. I eventually just copied the
module source from the registry to my modules repo and then just configured
it via tfvars, which got me over the hump in my experiments last night. But
I have to be able to make it work with my newly licensed library modules,
so I’ll either figure it out from the docs or make a support request.

On Tue, Oct 31, 2017 at 12:25 Yevgeniy Brikman [e-mail]
wrote:

But then it didn't work, anyway, due to the file name conflict.

Based on your usage, I don't see how there could be a file name conflict.
Terragrunt will download the module from your vpc-modules repo into a tmp
folder. It will then call terraform init on it, which should result in
the VPC module being downloaded from the Terraform registry into a
.terraform folder within the tmp folder.

Could you paste the log output from running Terragrunt?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-340879722,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqJ01rqCXrBxW9dtLfvebjs0NA2Z7ks5sx3QYgaJpZM4PxXd4
.

[brikis98]

OK, keep us posted!

You may find these two example repos helpful with setting up Terragrunt:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example

[ghost]

I still cannot get ANYTHING terragrunt to function correctly. I seem to be bouncing off as many as a half-dozen separate bugs, so my different attempts to workaround problems always just bang into another bug. I've had emails, phone conversations, purchased the gruntworks library, and read every word of available documentation but I'll be damned if I can get terragrunt to work in even the most basic context. Here's the VERY long email I just sent covering every single variation and the resulting error messages

---

This email actually maybe encapsulates 4 or 5 separate terraform and terrragrunt bugs, but it is possible that one bug is actually causing a domino effect to all the others. I cannot separate them since I cannot get even the most basic functionality to work when it comes to terragrunt.

$ terragrunt -version
terragrunt version v0.13.15
$ terraform -version
Terraform v0.10.8

When I specify a -terraform-source with the double-slash after the directory that represents the top of my modules repo, I get a warning that terraform was initialized in an empty directory and the path it uses in the logs is then missing the directory name ater the double-slash. If I leave the double-slash off, it actually works correctly, but it also emits a warning about missing double-slash in the terragrunt-source value (ignore the error at the end and look at the paths in the text output):

$ terragrunt init --terragrunt-source ../../../../../stem-infra//vpc_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:07:27 Running command: terraform --version
[terragrunt] 2017/11/01 19:07:27 Reading Terragrunt config file at /Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/01 19:07:27 Cleaning up existing *.tf files in /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/01 19:07:27 Downloading Terraform configurations from file:///Users/sgendler/src/stem/stem-infra into /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM using terraform init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:07:27 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:07:28 Running command: terraform init -backend-config=bucket=stem-terraform-state-bucket -backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate -backend-config=region=us-west-2 -backend-config=encrypt=true -backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m -from-module=file:///Users/sgendler/src/stem/stem-infra /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra"...
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] 2017/11/01 19:07:28 Copying files from /Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/01 19:07:28 Setting working directory to /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/01 19:07:28 Backend s3 has not changed.
[terragrunt] 2017/11/01 19:07:28 Running command: terraform init -backend-config=bucket=stem-terraform-state-bucket -backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate -backend-config=region=us-west-2 -backend-config=encrypt=true -backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
Downloading modules...

Initializing the backend...
Error getting plugins: module root: 
    module mgmt_vpc: required variable "aws_region" not set
    module mgmt_vpc: required variable "vpc_name" not set
[terragrunt] 2017/11/01 19:07:33 exit status 1

If I leave off the double-slash, I get the following output (the same holds true if I use absolute or relative path and if I include a trailing slash or not):

$ terragrunt init --terragrunt-source ../../../../../stem-infra/vpc_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:31:37 Running command: terraform --version
[terragrunt] 2017/11/01 19:31:37 Reading Terragrunt config file at /Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/01 19:31:37 WARNING: no double-slash (//) found in source URL /Users/sgendler/src/stem/stem-infra/vpc_mgmt. Relative paths in downloaded Terraform code may not work.
[terragrunt] 2017/11/01 19:31:37 Cleaning up existing *.tf files in /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/iZO4VuAlCkzTzqA4H4VI2GwKYAs
[terragrunt] 2017/11/01 19:31:37 Downloading Terraform configurations from file:///Users/sgendler/src/stem/stem-infra/vpc_mgmt into /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/iZO4VuAlCkzTzqA4H4VI2GwKYAs using terraform init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:31:37 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:31:38 Running command: terraform init -backend-config=bucket=stem-terraform-state-bucket -backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate -backend-config=region=us-west-2 -backend-config=encrypt=true -backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m -from-module=file:///Users/sgendler/src/stem/stem-infra/vpc_mgmt /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/iZO4VuAlCkzTzqA4H4VI2GwKYAs
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra/vpc_mgmt"...
Downloading modules...

Initializing the backend...
Error getting plugins: module root: 
    module mgmt_vpc: required variable "vpc_name" not set
    module mgmt_vpc: required variable "aws_region" not set
[terragrunt] 2017/11/01 19:31:41 exit status 1

Meanwhile, if I commit my code in the module repo, push it to origin, and then remove the terragrunt-source directive from the command entirely, I get a completely different error:

In the module repo:

$ git add -A
$ git commit
[develop 25f843b] bugs
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 390 bytes | 0 bytes/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/stems/stem-infra.git
   835d8a4..25f843b  develop -> develop

Now in the live repo:

$ terragrunt init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt] 2017/11/01 19:38:16 Running command: terraform --version
[terragrunt] 2017/11/01 19:38:16 Reading Terragrunt config file at /Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/01 19:38:16 Terraform files in /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/a5cQNEi863WkyLAUB3yQSFHlvbM/vpc_mgmt are up to date. Will not download again.
[terragrunt] 2017/11/01 19:38:16 Copying files from /Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/a5cQNEi863WkyLAUB3yQSFHlvbM/vpc_mgmt
[terragrunt] 2017/11/01 19:38:16 Setting working directory to /var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/a5cQNEi863WkyLAUB3yQSFHlvbM/vpc_mgmt
[terragrunt] 2017/11/01 19:38:16 Initializing remote state for the s3 backend
[terragrunt] 2017/11/01 19:38:17 Running command: terraform init -backend-config=encrypt=true -backend-config=dynamodb_table=terraform-lock-table -backend-config=bucket=stem-terraform-state-bucket -backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate -backend-config=region=us-west-2 -lock-timeout=20m
There are some problems with the configuration, described below.

The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.

Error: Error parsing /private/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/a5cQNEi863WkyLAUB3yQSFHlvbM/vpc_mgmt/main.tf: key '"${var.public_subnets_cidr_blocks}"' expected start of object ('{') or assignment ('=')


[terragrunt] 2017/11/01 19:38:17 exit status 1

It would seem that that error is because Terragrunt is totally failing to see that the file in the module repo has changed. I know it is using the correct branch for 2 reasons - first, I can see the ref in the URL. Second, the vpc_mgmt directory ONLY exists in the develop branch. It hasn't been merged into master. And those are the only 2 branches or tags. So it must be using the correct branch, but it is using an ancient version of the file that I have updated repeatedly over the last several hours while trying to figure this stuff out. When I look at the path in /private/var/folders..., I can see that there is a typo - one that I fixed 5 or 6 commits ago - and yes, I pushed the commits to origin. I even validated them via web browser. So terragrunt is most definitely failing to notice that the template in the module repo has been updated. It doesn't matter how long I wait after the commit before running init - so it isn't an eventual consistency problem.

Additionally, that command you gave me for inclusion in the terraform.tfvars file for setting extra tfvars files is not getting applied when I run terraform init . Which explains why it isn't picking up the aws_region and vpc_name variables, both of which are defined in region.tfvars and env.tfvars, respectively. If I run terragrunt plan without terragrunt init, it complains about missing modules, but I can see that the extra .tfvars files are included in the command. So it would seem that 'init' is, for some reason, not included in the output of get_terraform_commands_that_need_vars() even thought it is clearly a command that does need vars.

My modules repo looks like this:

stem-infra
stem-infra/vpc_mgmt
stem-infra/vpc_mgmt/main.tf
stem-infra/vpc_mgmt/outputs.tf
stem-infra/vpc_mgmt/vars.tf

main.tf looks like this:

terraform {
  backend "s3" {}
}

provider "aws" {
  region = "${var.aws_region}"
}

module mgmt_vpc {
  source = "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgmt?ref=v0.3.0"

  cidr_block                    = "${var.cidr_block}"
  public_subnet_cidr_blocks     = ["${var.public_subnet_cidr_blocks}"]
  private_subnet_cidr_blocks    = ["${var.private_subnet_cidr_blocks}"]
  num_nat_gateways              = "${var.num_nat_gateways}"
}

My live repo looks like this:

stem-envs/aws1
stem-envs/aws2
stem-envs/aws2/_global
stem-envs/aws2/account.tfvars
stem-envs/aws2/us-east-1
stem-envs/aws2/us-east-1/_global
stem-envs/aws2/us-east-1/_global/env.tfvars
stem-envs/aws2/us-east-1/_global/vpc_mgmt
stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
stem-envs/aws2/us-east-1/prod
stem-envs/aws2/us-east-1/prod/vpc_mgmt
stem-envs/aws2/us-east-1/region.tfvars
stem-envs/aws2/us-east-1/staging
stem-envs/aws2/us-east-1/test
stem-envs/README.md
stem-envs/terraform.tfvars

My outermost terraform.tfvars is as follows:

terragrunt = {
  remote_state {
    backend = "s3"

    config {
      bucket = "stem-terraform-state-bucket"
      key    = "${path_relative_to_include()}/terraform.tfstate"
      region = "us-west-2"
      encrypt = true
      dynamodb_table = "terraform-lock-table"
    }
  }

  terraform {
    extra_arguments "common_vars" {
      commands = ["${get_terraform_commands_that_need_vars()}"]

      optional_var_files = [
        "${get_tfvars_dir()}/${find_in_parent_folders("account.tfvars", "skip-account-if-does-not-exist")}",
        "${get_tfvars_dir()}/${find_in_parent_folders("region.tfvars", "skip-region-if-does-not-exist")}",
        "${get_tfvars_dir()}/${find_in_parent_folders("env.tfvars", "skip-env-if-does-not-exist")}",
        "${get_tfvars_dir()}/terraform.tfvars"
      ]
    }

    extra_arguments "retry_lock" {
      commands = ["${get_terraform_commands_that_need_locking()}"]
      arguments = ["-lock-timeout=20m"]
    }
  }
}

The vpc_mgmt/terraform.tfvars file looks like this:

terragrunt = {
  terraform {
    source = "git::ssh://[email protected]/stems/stem-infra.git//vpc_mgmt?ref=develop"
  }
  include {
    path = "${find_in_parent_folders()}"
  }
}

cidr_block = "10.0.0.0/8"

public_subnets_cidr_blocks = {
  AZ-0 = "10.0.1.0/16"
  AZ-1 = "10.0.10.0/16"
  AZ-2 = "10.0.20.0/16"
  AZ-3 = "10.0.30.0/16"
  AZ-4 = "10.0.40.0/16"
  AZ-5 = "10.0.50.0/16"
}

private_subnets_cidr_blocks = {
  AZ-0 = "10.1.1.0/16"
  AZ-1 = "10.1.10.0/16"
  AZ-2 = "10.1.20.0/16"
  AZ-3 = "10.1.30.0/16"
  AZ-4 = "10.1.40.0/16"
  AZ-5 = "10.1.50.0/16"
}

num_nat_gateways = 4

env.tfvars has:

vpc_name = "mgmt"

region.tfvars has:

aws_region = "us-east-1"

And for my final problem, I cannot find any mention, in any documentation anywhere, of a way to pass maps around as variables. How do I do the assignment? I can assign a list like this:

module "my_module" {
  source = "..."
  new_var = ["${var.old_var}"]
}

but

module "my_module" {
  source = "..."
  new_var = {"${var.old_var}"}
}

results in syntax errors. The documentation about variables AND the documentation about modules fails to provide an example of passing a list or a map from a template variable through to a module variable. It looks like maybe your modules just use the list assignment syntax, so maybe casting a list to a map does the correct thing automatically, but some documentation would be nice. Google searches result in old bugs about total inability to pass maps at all, but I think those are out of date. I'd test it and just see what happens but I can't because nothing works - and I have no idea if the reason nothing works is because of the maps. Or, at the very least if maps cannot be passed, there must be standard workaround for converting to strings and then parsing them back out, since I'm sure you cannot build your library without the ability to pass maps at all. It would be nice if such methods were published somewhere. The same goes for any other standard workarounds for functional deficiencies.

---

I'm starting to be convinced that the problem isn't user error, here, and that there are a whole host of bugs in the current release of terragrunt that actually prevent it from working at all, no matter how it is set up. Maybe it works once it is initialized and working, but it doesn't seem able to accomplish initialization. I sure cannot figure out any way to specify a source, either in terraform.tfvars or in -terragrunt-source, so I cannot work in github AND I cannot work on the local filesystem. I also cannot get terragrunt to recognize changes in the repo, so it would be trivially easy to accidentally push broken or old infrastructure once I did have working config.

Frankly, despite all of my positive feedback earlier today, the fact that I cannot get even the most basic of configuration to actually function after several days of time-wasting, many emails and posts to issues, a 90 minute support call, and reading every piece of documentation that is out there doesn't exactly give me warm and funzzy feelings about using terraform or terragrunt in a production environment. I still have yet to get a single thing to work (and I'm not exactly a novice when it comes to devops and configuration and infrastructure management), whether using publicly available modules or your gruntworks library and whether I use the practices in Evgeniy's book or incorporate some of the changes we discussed today. It just doesn't work, and I'll be damned if I can uncover a reason.

[josh-padnick]

@sgendler-stem Thank you for all the details, and I'm really sorry about the trouble you've been having. We actively maintain Terragrunt, have a battery of automated tests, and an active community of worldwide users, so this level of frustration is surprising.

First, there seem to be several cases where your code is returning Terraform errors, not Terragrunt errors. For example:

Error getting plugins: module root: 
    module mgmt_vpc: required variable "aws_region" not set
    module mgmt_vpc: required variable "vpc_name" not set

Error: Error parsing /private/var/.../vpc_mgmt/main.tf: key '"${var.public_subnets_cidr_blocks}"' expected start of object ('{') or assignment ('=')

are both Terraform errors, and:

new_var = {"${old_var}"}

is invalid HCL syntax.

That being said, it sounds like the temp folder where Terragrunt downloads module files may not be updating correctly, which would definitely be a Terragrunt issue.

Here are some immediate suggestions for a resolution:

1. First, can you send a ZIP of your entire Terraform config that is failing to [email protected]? I'd like to repro this issue and see if I can identify the root issue.

2. On your question regarding how to pass maps in the terraform.tfvars file, keep in mind that this file is pure HCL, and these are just key-value pairs. So here are some examples of valid syntax:

   # string
   new_var = "string"
   
   # boolean
   new_var = true 
   
   # int
   new_var = 0
   
   # list
   new_var = ["bert", "ernie"]
   
   # map
   new_var = {
     key1 = "val1"
     key2 = "Note that only strings are supported for map values"
   }
   

3. For the error required variable "aws_region" not set, this suggests that Terraform is missing this var. From our discussion earlier today, I'm assuming you intend to populate this from a region.vars file which is auto-populated by Terragrunt per https://github.com/gruntwork-io/terragrunt#required-and-optional-var-files.

   Can you double-check that your "leaf" terraform.tfvars file is using an include per https://github.com/gruntwork-io/terragrunt#filling-in-remote-state-settings-with-terragrunt? Do you have a region.tfvars file in a parent folder above that terraform.tfvars file? Does the "root" terraform.tfvars file include the syntax shown at https://github.com/gruntwork-io/terragrunt#required-and-optional-var-files?

4. Finally, one fail-safe way to get Terragrunt to refresh the cache is to use the --terragrunt-source-update option with any terragrunt command. This will flush the cache entirely and re-download everything from scratch. Keep in mind you can also look to see which tmp folder Terragrunt is using and visit it directly on your system to inspect what's there. You can even run terraform commands directly from that directory.

   I'd also encourage you to make use of the --terragrunt-source /local/path/to/module property, which will override whatever is in your source property in terraform.tfvars with the given value. This is especially handy for local development so that you don't have to push to git just to test your code.

I wish I had a more definitive resolution, but hopefully this gives you some leads. In the meantime, send us your full Terraform config, and we'll try to reproduce your issue. If we can reproduce your bugs, we'll gladly fix those.

Either way, we'll work this through to completion and identify the underlying causes of confusion, which surely will or already have tripped up others. The fact that you reached this level of frustration suggests that Terragrunt perhaps does not provide enough "guard rails" or makes a fundamental assumption that's not clear to the end user, so we'll consider what we can do to avoid those issues.

Thank you for your feedback!

[ghost]

Unfortunately, there's nothing in your response that I'm not already aware of. The terraform errors are a result of terragrunt errors. For example, since init isn't listed as a command that requires vars, it isn't picking up aws_region and vpc_name. The -from-module flag NEVER includes the module directory, whether I use // or / in the github url OR the terragrunt-source directory specification. I'd love to use -terragrunt-source so I don't have to fight with github for every minor change, but terragrunt-source would have to actually work correctly for me to do that.

I eventually fixed the lack of env.tfvars and region.tfvars by specifying the commands as:

commands = ["${get_terraform_commands_that_need_vars()}", "init"]

in order to add init to the list of commands that need vars - since I cannot use ${concat()} in a terraform.tfvars file, which seemed the more natural way to add items to a list.

Your examples of HCL syntax still don't explain how to assign lists and maps that are already contained in template variables, when trying to pass them to a module. I know I can do this:

var = "value"
var2 = ["value2", "value2"]
var3 = {
  key1 = "value1"
  key2 = "value2"
}

because that's pretty much the sum-total of documentation of how to initialize variables in all terraform and terragrunt docs.

and it seems that if I want to pass a list, I do the following:

var3 = ["${var.list_var}"]

But I picked that up by seeing examples rather than because it seems to be documented anywhere.

So it seemed natural to pass a map by doing the following:

var4 = {"${var.map_var}"}

but that results in a syntax error.

Maybe it's possible that this is perfectly legal (no quotes, so the value is just assigned straight across?)

var3 = ${var.list_var}

but this next variant would surely create a string rather than a list, no? And I have the impression that variable interpolation only happens inside quoted strings, so I'm not sure how this wouldn't result in a string being assigned to var4

var4 = "${var.list_var}"

which implies that the previous (var3) mechanism actually coerces the list to a comma-delimited string and then parses that string when it is passed as the value of a list, since it certainly doesn't seem to create a list of a list, which is what I would otherwise expect. So that leaves me with two assumptions - that I cannot pass a map from a template var to a module var or else that I have to do so by coercing the map to a list of alternating key and value and then parse that back into a map. If ["${var.my_list}"] coerces my_list into a string that gets parsed back into a list, then surely {"${var.my_map}"} would coerce a map into a string and parse it back into a map, right? Except that doesn't seem to be the case since it throws syntax errors. Instead, it seems that maybe coercing a map to a list gives me the alternative key and value list, and then coercing that list to a map does actually get me a map. Fine, I can live with that, but surely that's worth documenting somewhere? The HCL docs provide no clue, since they don't say one word about variable interpolation during assignment - a rather dramatic oversight in a language ostensibly designed for interpolation.

I'm guessing something like this might work:

var5 = {["${var.map_var}"]}

coercing the map to a list and the list to a map.

and it is possible that if var6 inside the module is a map type, that simply doing this ```var6 = ["${var.another_map_var}"] will cause the coercion to map to happen correctly when var6 is passed to the module, but again, that kind of coercion and parsing shouldn't be happening without some kind of explanation in a document somewhere - that's an enormous amount of coding by trial and error to figure out since it is far from the most obvious place to start, and for a feature that every single user is likely to get stuck on within their first day of using terragrunt and your library if they follow your suggested best-practices, since every module is going to get called from a template and pretty much every module receives at least one map in an input variable, so this problem must be encountered constantly by new users.

None of the isted tricks seemed to work, incidentally, since I'm setting a map for public and private subnets in my terraform.tfvars file, then in my vpc template's main.tf, I try to pass that to your vpc-mgmt module, but it is apparently not working because I am not picking up the subnets I specify in the map I am passing in. I believe I have tried every variant suggested in this comment, so I still do not see how I can get a map from terraform.tfvars in my live repo to be passed into my template vars and then into my module - the kind of thing I'd have thought might be covered in the first page of documentation for how to use your library, honestly, since absolutely anyone attempting to use it will surely have a structure pretty much identical to mine.

[ghost]

And for what it is worth, purging all of the source files results in huge delays while I wait 20+ minutes for provider plugins to download from Hashicorp. I'm not sure why those are so slow, but they are. The null provider required 5-10 minutes and each subsequent provider requires 2 or 3 minutes. It's very frustrating and completely eliminates the possibility of doing anything quickly, but I have to do it on every command or else I don't pick up the latest changes from github. It's not a networking problem, as I can pull the zip files from releases.hashicorp.com in a second or less. It's really not clear exactly what it is spending all of that time on.

I can download the aws provider from the server in a half second, but downloading the plugin via terraform/terragrunt requires 10+ minutes.

[ghost]

Finally, to add to the list of bugs/documentation problems, I included 5 or 6 subnets in my map, under the assumption that it would use 4 of them because that's how many availability zones there are. Instead, it seems to have used the size of my map to generate public and private subnets for imaginary availability zones, even while it didn't actually use the cidr blocks that my map provided for those subnets - public or private. That's a little disappointing.

Here's the bottom section of my plan output:

  + module.mgmt_vpc.aws_subnet.private[5]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1f"
      cidr_block:                       "10.120.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-private-5"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_subnet.public[0]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1a"
      cidr_block:                       "10.0.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-public-0"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_subnet.public[1]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1b"
      cidr_block:                       "10.8.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-public-1"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_subnet.public[2]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1c"
      cidr_block:                       "10.16.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-public-2"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_subnet.public[3]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1d"
      cidr_block:                       "10.24.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-public-3"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_subnet.public[4]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1e"
      cidr_block:                       "10.32.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-public-4"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_subnet.public[5]
      id:                               <computed>
      assign_ipv6_address_on_creation:  "false"
      availability_zone:                "us-east-1f"
      cidr_block:                       "10.40.0.0/13"
      ipv6_cidr_block:                  <computed>
      ipv6_cidr_block_association_id:   <computed>
      map_public_ip_on_launch:          "false"
      tags.%:                           "1"
      tags.Name:                        "mgmt-public-5"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_vpc.main
      id:                               <computed>
      assign_generated_ipv6_cidr_block: "false"
      cidr_block:                       "10.0.0.0/8"
      default_network_acl_id:           <computed>
      default_route_table_id:           <computed>
      default_security_group_id:        <computed>
      dhcp_options_id:                  <computed>
      enable_classiclink:               <computed>
      enable_classiclink_dns_support:   <computed>
      enable_dns_hostnames:             "true"
      enable_dns_support:               "true"
      instance_tenancy:                 "default"
      ipv6_association_id:              <computed>
      ipv6_cidr_block:                  <computed>
      main_route_table_id:              <computed>
      tags.%:                           "1"
      tags.Name:                        "mgmt"

  + module.mgmt_vpc.aws_vpc_endpoint.s3-private
      id:                               <computed>
      cidr_blocks.#:                    <computed>
      policy:                           <computed>
      prefix_list_id:                   <computed>
      route_table_ids.#:                <computed>
      service_name:                     "com.amazonaws.us-east-1.s3"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.aws_vpc_endpoint.s3-public
      id:                               <computed>
      cidr_blocks.#:                    <computed>
      policy:                           <computed>
      prefix_list_id:                   <computed>
      route_table_ids.#:                <computed>
      service_name:                     "com.amazonaws.us-east-1.s3"
      vpc_id:                           "${aws_vpc.main.id}"

  + module.mgmt_vpc.null_resource.vpc_ready
      id:                               <computed>

And here are the subnets that should have been assigned - I know the map must have been passed through correctly, since it does create 6 subnets in a region that only has 4 AZs, but the cidr blocks have no relationship to the cidr blocks in the maps I passed in.

cidr_block = "10.0.0.0/8"

public_subnets_cidr_blocks = {
  AZ-0 = "10.0.1.0/16"
  AZ-1 = "10.0.10.0/16"
  AZ-2 = "10.0.20.0/16"
  AZ-3 = "10.0.30.0/16"
  AZ-4 = "10.0.40.0/16"
  AZ-5 = "10.0.50.0/16"
}

private_subnets_cidr_blocks = {
  AZ-0 = "10.1.1.0/16"
  AZ-1 = "10.1.10.0/16"
  AZ-2 = "10.1.20.0/16"
  AZ-3 = "10.1.30.0/16"
  AZ-4 = "10.1.40.0/16"
  AZ-5 = "10.1.50.0/16"
}

num_nat_gateways = 4

[ghost]

Caught the typo in my CIDR blocks - but it didn't fix anything in the cidr assignments.

cidr_block = "10.0.0.0/16"

public_subnets_cidr_blocks = {
  AZ-0 = "10.0.1.0/22"
  AZ-1 = "10.0.10.0/22"
  AZ-2 = "10.0.20.0/22"
  AZ-3 = "10.0.30.0/22"
}

private_subnets_cidr_blocks = {
  AZ-0 = "10.0.100.0/22"
  AZ-1 = "10.0.110.0/22"
  AZ-2 = "10.0.120.0/22"
  AZ-3 = "10.0.130.0/22"
}

num_nat_gateways = 4

It turns out that my variable names had a typo in them - subnets shouldn't be plural. Is there a way to get terraform to be strict about variables passed to modules so that if a variable is passed in which is not in the inputs for the module it generates an error rather than silently using defaults?

[josh-padnick]

There are just too many interconnected issues to here respond to them effectively async. I'll PM you with a link and if you're available, we can chat real-time to resolve some of these issues.

[ghost]

I have everything working, finally. Some were simply typos in variable names (a strict mode would be super helpful here, as the error messages, if they exist at all, are often not that useful).

I worked around 'info' not being in the list of commands that require vars by appending it to the list.

module_map_var = "${var.template_map_var}" in the module block actually seems to do the correct thing, though it took me forever to get things running well enough to determine that since there was no documentation to suggest it and many list examples seemed to indicate that it wouldn't work correctly, since they all use square brackets around the interpolation string.

The --terragrunt-source flag and the source parameter in the module block do appear to be broken - the '//' that is supposed to precede the module name doesn't seem to get handled correctly and it generates warnings about empty directories - but then it does the correct thing under the hood, pulling the whole repo into the 'empty' directory, which results in the correct thing being pulled into the temp dir - but that is perhaps merely a lucky artifact resulting from using a module repo that keeps each module in the root of the repo, so it creates an empty temp dir and then pulls the entire content of the module repo into that empty temp dir. Since that creates a directory called vpc_mgmt as an accident of my naming convention, I seem to get lucky and terraform does the right thing even though the -from-module flag is incorrect in the terraform command, since the directory gets created accidentally. So it is working, but will cease to work as soon as I try to load a template that isn't one level deep inside my module repo or I use a template in a directory that doesn't match the name in the live repo. There are loads of warnings in the output, but at least it accidentally works.

provider downloads are super slow and I don't seem able to trust terragrunt/terraform to correctly detect changes in the module repo, whether using github/ssh or --terragrunt-source override, so I'm forced to suffer the slow downloads by clearing the temp files on every run.

[josh-padnick]

Great to see the issues are resolved.

I have everything working, finally. Some were simply typos in variable names

Ok, glad to see at least some items in here are user error. :)

(a strict mode would be super helpful here, as the error messages, if they exist at all, are often not that useful).

This is a general issue with Terraform (see #14324, #15377, and #15053), though I generally find the errors around missing variables are usually pretty clear. I'm not sure what Terragrunt could really do here...

I worked around 'info' not being in the list of commands that require vars by appending it to the list.

I think you mean terraform init? If you run terraform init --help you'll see that terraform init doesn't actually accept -var flags. Can you provide any additional info on this one? Given the length of this thread, it may be better to open that in a separate GitHub Issue.

module_map_var = "${var.template_map_var}" in the module block actually seems to do the correct thing

Yeah, the syntax for denoting lists and maps is inconsistent in Terraform. I can see how this could lead to some confusion while you're wrestling other issues.

The --terragrunt-source flag and the source parameter in the module block do appear to be broken

This sounds like it could be a Terragrunt issue, although it may be an issue with your template, or with Terraform. Can you paste the output that seems to be behaving strangely? Then we can determine whether this is the root issue that motivated this thread, a separate issue, or a mistake/bug elsewhere.

It may also help to know that we are about to merge https://github.com/gruntwork-io/terragrunt/pull/340 to resolve https://github.com/gruntwork-io/terragrunt/issues/334. One issue we've seen is that the OS will delete the _files_ in a temp folder, but not the folder itself, which would sometimes confuse Terragrunt.

provider downloads are super slow

I'm not experiencing that on my machine using all the same providers and git repos you are, so I'm not sure how to explain this one.

Next Steps
To keep this thread sane, let's try to focus on the known or suspected Terragrunt-specific issues. For other questions about using Gruntwork packages, it's best if you use our Gruntwork support channel.

Now that you're more familiar with some of the Terraform syntax quirks, it will hopefully be easier to separate Terraform errors from Terragrunt issues.

[ghost]

Here's the full output from the one and only run of apply that I've ever
executed - you can see that it is generating warnings about the '//' in the
source and claims that the resulting temp directory is empty (because it
is) before it pulls the whole github repo into that empty directory,
effectively creating the directory that was otherwise not created - only
because my template directory and the the directory name in the live repo
happen to be the same, as far as I can tell. I rendered the bits that are
pertinent in bold. I'm pretty sure you could replicate this locally and
possibly also break things entirely by just renaming the template file to
something different from the name of the directory in the live repo or vice
versa or by nesting the template directories in the module repo deeper
inside the repository so that they don't end up landing in the correct
place in the temp dir. That's just a hunch, though.

$ terragrunt apply --terragrunt-source
../../../../../stem-infra//vpc_mgmt/
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/01 22:51:29 Running command: terraform --version
[terragrunt] 2017/11/01 22:51:29 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/01 22:51:29 Cleaning up existing .tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/01 22:51:29 *Downloading Terraform configurations from
file:///Users/sgendler/src/stem/stem-infra into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
using terraform init
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/01 22:51:29 Backend s3 has not changed.
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/01 22:51:29 Running command: terraform init
-backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../../account.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
-lock-timeout=20m -from-module=file:///Users/sgendler/src/stem/stem-infra
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra"...
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] 2017/11/01 22:51:29 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt
into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/01 22:51:30 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/01 22:51:30 Backend s3 has not changed.
[terragrunt] 2017/11/01 22:51:30 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../../account.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
-lock-timeout=20m
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
module.mgmt_vpc.aws_vpc.main: Creating...
assign_generated_ipv6_cidr_block: "" => "false"
cidr_block: "" => "10.0.0.0/16"
default_network_acl_id: "" => ""
default_route_table_id: "" => ""
default_security_group_id: "" => ""
dhcp_options_id: "" => ""
enable_classiclink: "" => ""
enable_classiclink_dns_support: "" => ""
enable_dns_hostnames: "" => "true"
enable_dns_support: "" => "true"
instance_tenancy: "" => "default"
ipv6_association_id: "" => ""
ipv6_cidr_block: "" => ""
main_route_table_id: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt"
module.mgmt_vpc.aws_vpc.main: Creation complete after 9s (ID: vpc-b03e96c8)
module.mgmt_vpc.aws_route_table.private[0]: Creating...
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[2]: Creating...
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-2"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.public: Creating...
propagating_vgws.#: "" => ""
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-public"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[1]: Creating...
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-1"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[1]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1b"
cidr_block: "" => "10.0.10.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-1"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.private[1]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1b"
cidr_block: "" => "10.0.110.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-1"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_internet_gateway.main: Creating...
tags.%: "0" => "1"
tags.Name: "" => "mgmt"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[2]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1c"
cidr_block: "" => "10.0.20.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-2"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.private[2]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1c"
cidr_block: "" => "10.0.120.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-2"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[2]: Creation complete after 2s (ID:
rtb-a47c32de)
module.mgmt_vpc.aws_subnet.private[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.100.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.public: Creation complete after 3s (ID:
rtb-2078365a)
module.mgmt_vpc.aws_vpc_endpoint.s3-public: Creating...
cidr_blocks.#: "" => ""
policy: "" => ""
prefix_list_id: "" => ""
route_table_ids.#: "" => "1"
route_table_ids.3869909465: "" => "rtb-2078365a"
service_name: "" => "com.amazonaws.us-east-1.s3"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[0]: Creation complete after 3s (ID:
rtb-64632d1e)
module.mgmt_vpc.aws_route_table.private[1]: Creation complete after 3s (ID:
rtb-07632d7d)
module.mgmt_vpc.aws_vpc_endpoint.s3-private: Creating...
cidr_blocks.#: "" => ""
policy: "" => ""
prefix_list_id: "" => ""
route_table_ids.#: "" => "3"
route_table_ids.1216147752: "" => "rtb-07632d7d"
route_table_ids.2661709090: "" => "rtb-64632d1e"
route_table_ids.625676261: "" => "rtb-a47c32de"
service_name: "" => "com.amazonaws.us-east-1.s3"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[2]: Creation complete after 3s (ID:
subnet-c86b8195)
module.mgmt_vpc.aws_subnet.public[1]: Creation complete after 3s (ID:
subnet-310fbc7a)
module.mgmt_vpc.aws_subnet.private[2]: Creation complete after 3s (ID:
subnet-77678d2a)
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-797a8b56)
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-310fbc7a"
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-797a8b56"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_internet_gateway.main: Creation complete after 3s (ID:
igw-0348f57a)
module.mgmt_vpc.aws_eip.nat: Creating...
allocation_id: "" => ""
association_id: "" => ""
domain: "" => ""
instance: "" => ""
network_interface: "" => ""
private_ip: "" => ""
public_ip: "" => ""
vpc: "" => "true"
module.mgmt_vpc.aws_route.internet: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => "igw-0348f57a"
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => ""
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-2078365a"
state: "" => ""
module.mgmt_vpc.aws_subnet.private[1]: Creation complete after 3s (ID:
subnet-fa08bbb1)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 1s (ID: rtbassoc-4902b734)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 1s (ID: rtbassoc-2f00b552)
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 1s (ID: rtbassoc-bc06b3c1)
module.mgmt_vpc.aws_eip.nat: Creation complete after 1s (ID:
eipalloc-85c69ab0)
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-797a8b56"
module.mgmt_vpc.aws_route.internet: Creation complete after 1s (ID:
r-rtb-2078365a1080289494)
module.mgmt_vpc.aws_vpc_endpoint.s3-public: Creation complete after 1s (ID:
vpce-753e8e1c)
module.mgmt_vpc.aws_vpc_endpoint.s3-private: Creation complete after 2s
(ID: vpce-df3686b6)
module.mgmt_vpc.aws_subnet.private[0]: Creation complete after 3s (ID:
subnet-77649558)
module.mgmt_vpc.aws_route_table_association.private[0]: Creating...
route_table_id: "" => "rtb-64632d1e"
subnet_id: "" => "subnet-77649558"
module.mgmt_vpc.aws_route_table_association.private[2]: Creating...
route_table_id: "" => "rtb-a47c32de"
subnet_id: "" => "subnet-77678d2a"
module.mgmt_vpc.aws_route_table_association.private[1]: Creating...
route_table_id: "" => "rtb-07632d7d"
subnet_id: "" => "subnet-fa08bbb1"
module.mgmt_vpc.aws_route_table_association.private[1]: Creation complete
after 0s (ID: rtbassoc-ef0bbe92)
module.mgmt_vpc.aws_route_table_association.private[2]: Creation complete
after 0s (ID: rtbassoc-2e00b553)
module.mgmt_vpc.aws_route_table_association.private[0]: Creation complete
after 0s (ID: rtbassoc-a4f440d9)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 1m32s (ID:
nat-0711956af38d29715)
module.mgmt_vpc.aws_route.nat[2]: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => ""
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => "nat-0711956af38d29715"
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-a47c32de"
state: "" => ""
module.mgmt_vpc.aws_route.nat[1]: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => ""
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => "nat-0711956af38d29715"
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-07632d7d"
state: "" => ""
module.mgmt_vpc.aws_route.nat[0]: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => ""
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => "nat-0711956af38d29715"
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-64632d1e"
state: "" => ""
module.mgmt_vpc.aws_route.nat[0]: Creation complete after 1s (ID:
r-rtb-64632d1e1080289494)
module.mgmt_vpc.aws_route.nat[1]: Creation complete after 2s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[2]: Creation complete after 2s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.null_resource.vpc_ready: Creating...
module.mgmt_vpc.null_resource.vpc_ready: Creation complete after 0s (ID:
3854081390465364666)

Apply complete! Resources: 27 added, 0 changed, 0 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.108.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-fa08bbb1,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.8.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-797a8b56,
subnet-310fbc7a,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

On Wed, Nov 1, 2017 at 11:46 PM, Josh Padnick [e-mail]
wrote:

Great to see the issues are resolved.

I have everything working, finally. Some were simply typos in variable
names

Ok, glad to see at least some items in here are user error. :)

(a strict mode would be super helpful here, as the error messages, if they
exist at all, are often not that useful).

This is a general issue with Terraform (see #14324
https://github.com/hashicorp/terraform/issues/14324, #15377
https://github.com/hashicorp/terraform/issues/15377, and #15053
https://github.com/hashicorp/terraform/issues/15053), though I
generally find the errors around missing variables are usually pretty
clear. I'm not sure what Terragrunt could really do here...

I worked around 'info' not being in the list of commands that require vars
by appending it to the list.

I think you mean terraform init? If you run terraform init --help you'll
see that terraform init doesn't actually accept -var flags. Can you
provide any additional info on this one? Given the length of this thread,
it may be better to open that in a separate GitHub Issue.

module_map_var = "${var.template_map_var}" in the module block actually
seems to do the correct thing

Yeah, the syntax for denoting lists and maps is inconsistent in Terraform.
I can see how this could lead to some confusion while you're wrestling
other issues.

The --terragrunt-source flag and the source parameter in the module block
do appear to be broken

This sounds like it could be a Terragrunt issue, although it may be an
issue with your template, or with Terraform. Can you paste the output that
seems to be behaving strangely? Then we can determine whether this is the root
issue that motivated this thread
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-335003078,
a separate issue, or a mistake/bug elsewhere.

It may also help to know that we are about to merge #340
https://github.com/gruntwork-io/terragrunt/pull/340 to resolve #334
https://github.com/gruntwork-io/terragrunt/issues/334. One issue we've
seen is that the OS will delete the files in a temp folder, but not the
folder itself, which would sometimes confuse Terragrunt.

provider downloads are super slow

I'm not experiencing that on my machine using all the same providers and
git repos you are, so I'm not sure how to explain this one.

Next Steps
To keep this thread sane, let's try to focus on the known or suspected
Terragrunt-specific issues. For other questions about using Gruntwork
packages, it's best if you use our Gruntwork support channel.

Now that you're more familiar with some of the Terraform syntax quirks, it
will hopefully be easier to separate Terraform errors from Terragrunt
issues.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341332091,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqD3i1ZPg3Ykuikn73218wiHz9gdnks5syWVLgaJpZM4PxXd4
.

[ghost]

Oh, and the thing that would be useful on the variable front is a warning
or error if you pass a variable to a module which isn't defined in its
inputs. My problems weren't so much a result of not providing required
variables, since that error message is somewhat obvious. My problems
stemmed from ending up with default values because the variables I was
passing in had typos in them. So I want a warning or error when I try to
use a variable that isn't a valid input. If I had been notified of that, I
would have spotted the typos much sooner. Instead, it just silently went
with the defaults. Or maybe it wasn't silent but was buried under the
noise of the other bugs I was encountering or the normal output.

On Thu, Nov 2, 2017 at 12:01 AM, Samuel Gendler [e-mail] wrote:

Here's the full output from the one and only run of apply that I've ever
executed - you can see that it is generating warnings about the '//' in the
source and claims that the resulting temp directory is empty (because it
is) before it pulls the whole github repo into that empty directory,
effectively creating the directory that was otherwise not created - only
because my template directory and the the directory name in the live repo
happen to be the same, as far as I can tell. I rendered the bits that are
pertinent in bold. I'm pretty sure you could replicate this locally and
possibly also break things entirely by just renaming the template file to
something different from the name of the directory in the live repo or vice
versa or by nesting the template directories in the module repo deeper
inside the repository so that they don't end up landing in the correct
place in the temp dir. That's just a hunch, though.

$ terragrunt apply --terragrunt-source
../../../../../stem-infra//vpc_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/01 22:51:29 Running command: terraform --version
[terragrunt] 2017/11/01 22:51:29 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/
vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/01 22:51:29 Cleaning up existing .tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/01 22:51:29 *Downloading Terraform configurations
from file:///Users/sgendler/src/stem/stem-infra into /var/folders/xr/
t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
using terraform init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/01 22:51:29 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/01 22:51:29 Running command: terraform init
-backend-config=encrypt=true -backend-config=dynamodb_table=terraform-lock-table
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../../account.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/../../region.tfvars -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/terraform.tfvars -lock-timeout=20m -from-module=file:///Users/sgendler/src/stem/stem-infra
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra
"...
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] 2017/11/01 22:51:29 Copying files from /Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt
into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/01 22:51:30 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/01 22:51:30 Backend s3 has not changed.
[terragrunt] 2017/11/01 22:51:30 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/../../../account.tfvars -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/terraform.tfvars -lock-timeout=20m
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
module.mgmt_vpc.aws_vpc.main: Creating...
assign_generated_ipv6_cidr_block: "" => "false"
cidr_block: "" => "10.0.0.0/16"
default_network_acl_id: "" => ""
default_route_table_id: "" => ""
default_security_group_id: "" => ""
dhcp_options_id: "" => ""
enable_classiclink: "" => ""
enable_classiclink_dns_support: "" => ""
enable_dns_hostnames: "" => "true"
enable_dns_support: "" => "true"
instance_tenancy: "" => "default"
ipv6_association_id: "" => ""
ipv6_cidr_block: "" => ""
main_route_table_id: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt"
module.mgmt_vpc.aws_vpc.main: Creation complete after 9s (ID: vpc-b03e96c8)
module.mgmt_vpc.aws_route_table.private[0]: Creating...
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[2]: Creating...
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-2"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.public: Creating...
propagating_vgws.#: "" => ""
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-public"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[1]: Creating...
route.#: "" => ""
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-1"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[1]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1b"
cidr_block: "" => "10.0.10.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-1"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.private[1]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1b"
cidr_block: "" => "10.0.110.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-1"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_internet_gateway.main: Creating...
tags.%: "0" => "1"
tags.Name: "" => "mgmt"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[2]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1c"
cidr_block: "" => "10.0.20.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-2"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.private[2]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1c"
cidr_block: "" => "10.0.120.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-2"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[2]: Creation complete after 2s
(ID: rtb-a47c32de)
module.mgmt_vpc.aws_subnet.private[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.100.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-private-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.public: Creation complete after 3s (ID:
rtb-2078365a)
module.mgmt_vpc.aws_vpc_endpoint.s3-public: Creating...
cidr_blocks.#: "" => ""
policy: "" => ""
prefix_list_id: "" => ""
route_table_ids.#: "" => "1"
route_table_ids.3869909465 <(386)%20990-9465>: "" => "rtb-2078365a"
service_name: "" => "com.amazonaws.us-east-1.s3"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_route_table.private[0]: Creation complete after 3s
(ID: rtb-64632d1e)
module.mgmt_vpc.aws_route_table.private[1]: Creation complete after 3s
(ID: rtb-07632d7d)
module.mgmt_vpc.aws_vpc_endpoint.s3-private: Creating...
cidr_blocks.#: "" => ""
policy: "" => ""
prefix_list_id: "" => ""
route_table_ids.#: "" => "3"
route_table_ids.1216147752: "" => "rtb-07632d7d"
route_table_ids.2661709090: "" => "rtb-64632d1e"
route_table_ids.625676261: "" => "rtb-a47c32de"
service_name: "" => "com.amazonaws.us-east-1.s3"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[2]: Creation complete after 3s (ID:
subnet-c86b8195)
module.mgmt_vpc.aws_subnet.public[1]: Creation complete after 3s (ID:
subnet-310fbc7a)
module.mgmt_vpc.aws_subnet.private[2]: Creation complete after 3s (ID:
subnet-77678d2a)
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-797a8b56)
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-310fbc7a"
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-797a8b56"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_internet_gateway.main: Creation complete after 3s
(ID: igw-0348f57a)
module.mgmt_vpc.aws_eip.nat: Creating...
allocation_id: "" => ""
association_id: "" => ""
domain: "" => ""
instance: "" => ""
network_interface: "" => ""
private_ip: "" => ""
public_ip: "" => ""
vpc: "" => "true"
module.mgmt_vpc.aws_route.internet: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => "igw-0348f57a"
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => ""
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-2078365a"
state: "" => ""
module.mgmt_vpc.aws_subnet.private[1]: Creation complete after 3s (ID:
subnet-fa08bbb1)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 1s (ID: rtbassoc-4902b734)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 1s (ID: rtbassoc-2f00b552)
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 1s (ID: rtbassoc-bc06b3c1)
module.mgmt_vpc.aws_eip.nat: Creation complete after 1s (ID:
eipalloc-85c69ab0)
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-797a8b56"
module.mgmt_vpc.aws_route.internet: Creation complete after 1s (ID:
r-rtb-2078365a1080289494)
module.mgmt_vpc.aws_vpc_endpoint.s3-public: Creation complete after 1s
(ID: vpce-753e8e1c)
module.mgmt_vpc.aws_vpc_endpoint.s3-private: Creation complete after 2s
(ID: vpce-df3686b6)
module.mgmt_vpc.aws_subnet.private[0]: Creation complete after 3s (ID:
subnet-77649558)
module.mgmt_vpc.aws_route_table_association.private[0]: Creating...
route_table_id: "" => "rtb-64632d1e"
subnet_id: "" => "subnet-77649558"
module.mgmt_vpc.aws_route_table_association.private[2]: Creating...
route_table_id: "" => "rtb-a47c32de"
subnet_id: "" => "subnet-77678d2a"
module.mgmt_vpc.aws_route_table_association.private[1]: Creating...
route_table_id: "" => "rtb-07632d7d"
subnet_id: "" => "subnet-fa08bbb1"
module.mgmt_vpc.aws_route_table_association.private[1]: Creation complete
after 0s (ID: rtbassoc-ef0bbe92)
module.mgmt_vpc.aws_route_table_association.private[2]: Creation complete
after 0s (ID: rtbassoc-2e00b553)
module.mgmt_vpc.aws_route_table_association.private[0]: Creation complete
after 0s (ID: rtbassoc-a4f440d9)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 1m32s (ID:
nat-0711956af38d29715)
module.mgmt_vpc.aws_route.nat[2]: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => ""
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => "nat-0711956af38d29715"
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-a47c32de"
state: "" => ""
module.mgmt_vpc.aws_route.nat[1]: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => ""
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => "nat-0711956af38d29715"
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-07632d7d"
state: "" => ""
module.mgmt_vpc.aws_route.nat[0]: Creating...
destination_cidr_block: "" => "0.0.0.0/0"
destination_prefix_list_id: "" => ""
egress_only_gateway_id: "" => ""
gateway_id: "" => ""
instance_id: "" => ""
instance_owner_id: "" => ""
nat_gateway_id: "" => "nat-0711956af38d29715"
network_interface_id: "" => ""
origin: "" => ""
route_table_id: "" => "rtb-64632d1e"
state: "" => ""
module.mgmt_vpc.aws_route.nat[0]: Creation complete after 1s (ID:
r-rtb-64632d1e1080289494)
module.mgmt_vpc.aws_route.nat[1]: Creation complete after 2s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[2]: Creation complete after 2s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.null_resource.vpc_ready: Creating...
module.mgmt_vpc.null_resource.vpc_ready: Creation complete after 0s (ID:
3854081390465364666)

Apply complete! Resources: 27 added, 0 changed, 0 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.108.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-fa08bbb1,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.8.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-797a8b56,
subnet-310fbc7a,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

On Wed, Nov 1, 2017 at 11:46 PM, Josh Padnick [e-mail]
wrote:

Great to see the issues are resolved.

I have everything working, finally. Some were simply typos in variable
names

Ok, glad to see at least some items in here are user error. :)

(a strict mode would be super helpful here, as the error messages, if
they exist at all, are often not that useful).

This is a general issue with Terraform (see #14324
https://github.com/hashicorp/terraform/issues/14324, #15377
https://github.com/hashicorp/terraform/issues/15377, and #15053
https://github.com/hashicorp/terraform/issues/15053), though I
generally find the errors around missing variables are usually pretty
clear. I'm not sure what Terragrunt could really do here...

I worked around 'info' not being in the list of commands that require
vars by appending it to the list.

I think you mean terraform init? If you run terraform init --help you'll
see that terraform init doesn't actually accept -var flags. Can you
provide any additional info on this one? Given the length of this thread,
it may be better to open that in a separate GitHub Issue.

module_map_var = "${var.template_map_var}" in the module block actually
seems to do the correct thing

Yeah, the syntax for denoting lists and maps is inconsistent in
Terraform. I can see how this could lead to some confusion while you're
wrestling other issues.

The --terragrunt-source flag and the source parameter in the module block
do appear to be broken

This sounds like it could be a Terragrunt issue, although it may be an
issue with your template, or with Terraform. Can you paste the output that
seems to be behaving strangely? Then we can determine whether this is the root
issue that motivated this thread
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-335003078,
a separate issue, or a mistake/bug elsewhere.

It may also help to know that we are about to merge #340
https://github.com/gruntwork-io/terragrunt/pull/340 to resolve #334
https://github.com/gruntwork-io/terragrunt/issues/334. One issue we've
seen is that the OS will delete the files in a temp folder, but not
the folder itself, which would sometimes confuse Terragrunt.

provider downloads are super slow

I'm not experiencing that on my machine using all the same providers and
git repos you are, so I'm not sure how to explain this one.

Next Steps
To keep this thread sane, let's try to focus on the known or suspected
Terragrunt-specific issues. For other questions about using Gruntwork
packages, it's best if you use our Gruntwork support channel.

Now that you're more familiar with some of the Terraform syntax quirks,
it will hopefully be easier to separate Terraform errors from Terragrunt
issues.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341332091,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqD3i1ZPg3Ykuikn73218wiHz9gdnks5syWVLgaJpZM4PxXd4
.

[brikis98]

Hi @sgendler-stem. Looks like you've had quite an adventure :-D

It looks like you finally got things working at the end, and this is a very long and hard-to-follow thread, but I'll try to respond to a few things in case it's helpful.

I seem to be bouncing off as many as a half-dozen separate bugs, so my different attempts to workaround problems always just bang into another bug.

That sucks. It sounds like a classic case of yak shaving, and unfortunately, it's a very common thing in DevOps, regardless of what tooling you're using.

I'm starting to be convinced that the problem isn't user error, here, and that there are a whole host of bugs in the current release of terragrunt that actually prevent it from working at all, no matter how it is set up.

We built Terragrunt because we ran into a number of shortcomings with Terraform. We figured most people in the open source world had the same issues as us, so we open sourced it, and do our best to maintain it, but it's not a requirement for using Terraform or any of Gruntwork's stuff at all, so if it's not working for you, it's OK not to use it!

That said, Terragrunt is used by a large number of companies, has thorough tests, and I use it almost every single day, so like Josh, I'm surprised you ran into a "whole host of bugs." Do you have a final list of what these bugs turned out to be? Or did they end up being mostly usage issues? If so, I'm guessing those could've been avoided with better docs or examples. Do you have thoughts on what sorts of example code we could add so people could have a smoother start in the future?

When I specify a -terraform-source with the double-slash after the directory that represents the top of my modules repo, I get a warning that terraform was initialized in an empty directory and the path it uses in the logs is then missing the directory name ater the double-slash.

You can safely ignore this. It's a warning from Terraform, not Terragrunt, it's not an error, and should not cause any issues.

If you're interested, here's some context. When you point the source parameter in your Terragrunt configuration at a module foo in some repo, Terragrunt needs to download foo into a tmp folder. If it downloads just foo, and under the hood foo pulls in another module bar using a relative path (e.g., module { source = "../bar" }), that relative path would break.

Therefore, Terragrunt allows you to specify a double-slash in your source parameter (e.g., source = "git::[email protected]:foo/modules.git//modules/foo") to specify where the "root" of your modules repo is. When you specify a double slash, instead of downloading just foo, Terragrunt downloads the entire repo (including bar), and sets the working directory to foo.

Under the hood, Terragrunt uses terraform init to do the downloading. That way, you can use all the same protocols in the source parameter (e.g., git, http, etc) of your Terragrunt config as those supported by the source parameter in Terraform's module { source = "..." } config. The one drawback here is that when we call init on the root of your repo (when there's a double-slash), if you don't have Terraform code directly in the root of that repo, Terraform shows a warning. That warning is completely harmless, because Terragrunt will set the working directory to your module (foo) shortly after, and the module does have Terraform code in it.

Meanwhile, if I commit my code in the module repo, push it to origin, and then remove the terragrunt-source directive from the command entirely, I get a completely different error:

Normally, when iterating locally and making rapid changes, you should use the --terragrunt-source parameter to use your local checkout instead of downloading from Git. If you do use Git, then either you need to release a new tag each time, or update the ref to the commit ID each time, or use the --terragrunt-source-update to tell Terragrunt to redowload the code from scratch.

The reason for this is that Terragrunt tries to avoid downloading the same thing multiple times. If it downloaded everything from scratch every time, every command would have 10 - 90 seconds of overhead as Terragrunt waited to download the code, download the provider plugins, download modules, and so on. So the assumption is that if you give Terragrunt a Git URL, it'll download it once, and not again. Terraform's behavior with modules is identical. If you want to force a redownload, you have to run with --terragrunt-source-update (for Terragrunt) or -update (for Terraform).

Obviously, this slows things down, so for local iteration, using --terragrunt-source and ignoring that warning is the way to go.

So it would seem that 'init' is, for some reason, not included in the output of get_terraform_commands_that_need_vars() even thought it is clearly a command that does need vars.

Does it? If you run terraform init --help it does NOT list -var or -var-file flags as supported...

The documentation about variables AND the documentation about modules fails to provide an example of passing a list or a map from a template variable through to a module variable.
var3 = ["${var.list_var}"]

Terragrunt uses .tfvars files for its configuration. These are not something invented by Terragrunt, but the normal files used in Terraform for variables. The syntax is HCL, so maps and lists use normal HCL syntax. It looks like your issue isn't about lists or maps, but trying to use interpolation in the .tfvars file.

Currently, Terraform does not support interpolation in .tfvars files. With Terragrunt, as explained in the docs, we added limited interpolation supported within the terragrunt = { ... } block. Arbitrary interpolations, variable references, concat, etc are not yet supported (see #132 for a discussion).

Can you explain the use case for these interpolations a bit more so I can offer alternative ways of doing it?

And for what it is worth, purging all of the source files results in huge delays while I wait 20+ minutes for provider plugins to download from Hashicorp. I'm not sure why those are so slow, but they are. The null provider required 5-10 minutes and each subsequent provider requires 2 or 3 minutes.

Hm, odd. Is your Internet speed working OK otherwise?

At any rate, consider enabling the provider plugin cache to avoid having to download the same thing multiple times.

I included 5 or 6 subnets in my map, under the assumption that it would use 4 of them because that's how many availability zones there are. Instead, it seems to have used the size of my map to generate public and private subnets for imaginary availability zones, even while it didn't actually use the cidr blocks that my map provided for those subnets - public or private.

This is not related to Terragrunt at all, but an issue specifically with the module-vpc code. Could you please file an issue in that repo so we can track it appropriately?

Oh, and the thing that would be useful on the variable front is a warning or error if you pass a variable to a module which isn't defined in its inputs.

Ah, I agree this would be handy. This isn't a Terragrunt issue, of course, as the same thing happens if you run Terraform directly with typos in the -var param or .tfvars files. I do wish they would fix it though!

[ghost]

Thanks, the explanation of what is going on with the path lunging was very
helpful. You should write that up somewhere public. And yak shaving - I
enjoyed that. Except now I’m going to see it everywhere because I have a
label for it!

And yeah, I figured most of those were terraform bugs, but I also figure
anyone who has literally written the book on terraform probably has the ear
of the dev team if he isn’t a committer himself ;-)

Anyway, I’m off and running. It’ll be interesting to see how fast I can
move with it now that I’m up and running. Ah, that’s it. That’s what needs
to get out there - a starter implementation that is just a mostly empty
pair of repositories but with just enough to demonstrate all of the common
practices - cascading environment, region, and account vars, etc.
basically, exactly the pair of repos I sent last night, plus maybe
something about IAM best practices so that people are doing the right thing
from the start - it can be harder to add that stuff in later. Your
terragrunt docs introduce all of the pieces but leaves combining them as an
exercise to the user - and my experience shows that the process is complex
enough that, when user error is combined with bugs and interface changes in
fast-moving software that can leave the docs lagging, it can be pretty hard
to put together a working system from scratch. Not a reference
architecture, just a reference terragrunt implementation.

On Thu, Nov 2, 2017 at 04:50 Yevgeniy Brikman [e-mail]
wrote:

Hi @sgendler-stem https://github.com/sgendler-stem. Looks like you've
had quite an adventure :-D

It looks like you finally got things working at the end, and this is a
very long and hard-to-follow thread, but I'll try to respond to a few
things in case it's helpful.

I seem to be bouncing off as many as a half-dozen separate bugs, so my
different attempts to workaround problems always just bang into another bug.

That sucks. It sounds like a classic case of yak shaving
https://blog.gruntwork.io/introducing-the-yak-shaving-series-247e7f20f81,
and unfortunately, it's a very common thing in DevOps, regardless of what
tooling you're using.

I'm starting to be convinced that the problem isn't user error, here, and
that there are a whole host of bugs in the current release of terragrunt
that actually prevent it from working at all, no matter how it is set up.

We built Terragrunt because we ran into a number of shortcomings with
Terraform. We figured most people in the open source world had the same
issues as us, so we open sourced it, and do our best to maintain it, but
it's not a requirement for using Terraform or any of Gruntwork's stuff at
all, so if it's not working for you, it's OK not to use it!

That said, Terragrunt is used by a large number of companies, has thorough
tests, and I use it almost every single day, so like Josh, I'm surprised
you ran into a "whole host of bugs." Do you have a final list of what these
bugs turned out to be? Or did they end up being mostly usage issues? If so,
I'm guessing those could've been avoided with better docs or examples. Do
you have thoughts on what sorts of example code we could add so people
could have a smoother start in the future?

When I specify a -terraform-source with the double-slash after the
directory that represents the top of my modules repo, I get a warning that
terraform was initialized in an empty directory and the path it uses in the
logs is then missing the directory name ater the double-slash.

You can safely ignore this. It's a warning from Terraform, not Terragrunt,
it's not an error, and should not cause any issues.

If you're interested, here's some context. When you point the source
parameter in your Terragrunt configuration to at a module foo in a repo,
Terragrunt needs to download foo into a tmp folder. If it downloads just
foo, and under the hood foo pulls in another module bar using a relative
path (e.g., module { source = "../bar" }), that relative path would break.

Therefore, Terragrunt allows you to specify a double-slash in your source
parameter (e.g., source = "git::[email protected]:
foo/modules.git//modules/foo") to specify where the "root" of your
modules repo is. When you specify a double slash, instead of downloading
just foo, Terragrunt downloads the entire repo (including bar), and sets
the working directory to foo.

Under the hood, Terragrunt uses terraform init to do the downloading.
That way, you can use all the same protocols in the source parameter
(e.g., git, http, etc) of your Terragrunt config as those supported by the
source parameter in Terraform's module { source = "..." } config. The one
drawback here is that when we call init on the root of your repo (when
there's a double-slash), if you don't have Terraform code directly in the
root of that repo, Terraform shows a warning. That warning is completely
harmless, because Terragrunt will set the working directory to your module (
foo) shortly after, and the module does have Terraform code in it.

Meanwhile, if I commit my code in the module repo, push it to origin, and
then remove the terragrunt-source directive from the command entirely, I
get a completely different error:

Normally, when iterating locally and making rapid changes, you should use
the --terragrunt-source parameter to use your local checkout instead of
downloading from Git. If you do use Git, then either you need to release a
new tag each time, or update the ref to the commit ID each time, or use
the --terragrunt-source-update to tell Terragrunt to redowload the code
from scratch.

The reason for this is that Terragrunt tries to avoid downloading the same
thing multiple times. If it downloaded everything from scratch every time,
every command would have 10 - 90 seconds of overhead as Terragrunt waited
to download the code, download the provider plugins, download modules, and
so on. So the assumption is that if you give Terragrunt a Git URL, it'll
download it once, and not again. Terraform's behavior with module's is
identical. If you want to force a redownload, you have to run with
--terragrunt-source-update (for Terragrunt) or -update (for Terraform).

So it would seem that 'init' is, for some reason, not included in the
output of get_terraform_commands_that_need_vars() even thought it is
clearly a command that does need vars.

Does it? If you run terraform init --help it does NOT list -var or
-var-file flags as supported...

The documentation about variables AND the documentation about modules
fails to provide an example of passing a list or a map from a template
variable through to a module variable.
var3 = ["${var.list_var}"]

Terragrunt uses .tfvars files for its configuration. These are not
something invented by Terragrunt, but the normal files used in Terraform
for variables
https://www.terraform.io/intro/getting-started/variables.html#from-a-file.
The syntax is HCL, so maps and lists use normal HCL syntax. It looks like
your issue isn't about lists or maps, but trying to use interpolation
in the .tfvars file.

Currently, Terraform does not support interpolation in .tfvars files
https://github.com/hashicorp/terraform/issues/10059. With Terragrunt, as
explained in the docs
https://github.com/gruntwork-io/terragrunt#interpolation-syntax, we
added limited interpolation supported within the terragrunt = { ... }
block.

Can you explain the use case for these interpolations a bit more so I can
offer alternative ways of doing it?

And for what it is worth, purging all of the source files results in huge
delays while I wait 20+ minutes for provider plugins to download from
Hashicorp. I'm not sure why those are so slow, but they are. The null
provider required 5-10 minutes and each subsequent provider requires 2 or 3
minutes.

Hm, odd. Is your Internet speed working OK otherwise?

At any rate, consider enabling the provider plugin cache
https://www.terraform.io/docs/configuration/providers.html#provider-plugin-cache
to avoid having to download the same thing multiple times.

I included 5 or 6 subnets in my map, under the assumption that it would
use 4 of them because that's how many availability zones there are.
Instead, it seems to have used the size of my map to generate public and
private subnets for imaginary availability zones, even while it didn't
actually use the cidr blocks that my map provided for those subnets -
public or private.

This is not related to Terragrunt at all, but an issue specifically with
the module-vpc code. Could you please file an issue in that repo so we can
track it appropriately?

Oh, and the thing that would be useful on the variable front is a warning
or error if you pass a variable to a module which isn't defined in its
inputs.

Ah, I agree this would be handy. This is something Terraform should
implement, not Terragrunt.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341397951,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGWfOkXY1_pUCckGAE7HEyJW7ZI2ks5syayYgaJpZM4PxXd4
.

[brikis98]

Thanks, the explanation of what is going on with the path lunging was very helpful. You should write that up somewhere public.

Glad it helped. I added it here: https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is just a mostly empty pair of repositories but with just enough to demonstrate all of the common practices - cascading environment, region, and account vars, etc. basically, exactly the pair of repos I sent last night, plus maybe something about IAM best practices so that people are doing the right thing from the start - it can be harder to add that stuff in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture has all of that, and then some!

[ghost]

Yeah, but they actually lack all of the important parts that I was looking
for examples of - they don't demonstrate how to access a module from within
a template since they only use resources directly within the *.tf files,
and they don't show the cascading variable overrides and instead of
including empty directories for _global and region and account layers in
the hierarchy in order to demonstrate the concepts, those dirs are entirely
missing. That stuff took me 2 full days to get working due to a combination
of user error, bugs, and lack of documentation. I found those repos within
my first 20 minutes of exploration and was using them as my model, but I
still couldn't get modules to work from within the modules repo (which
should maybe be called the templates repo in order to avoid a lot of
unnecessary confusion over the difference between templates and modules).
I scoured the internet and your book for examples that combined terragrunt
with the use of modules in a template and they just don't seem to exist,
which is odd, since your reference architecture consists of almost nothing
but that exact pattern, I suspect. What I was looking for was
production-ready example repos that just have a minimum of templates and
configurations but are otherwise production-ready, whereas those really are
just quick examples of very simplistic code organization.

I was basically on the right track from the get go, but kept undoing
progress when bugs/user error would cause my experiments to fail even when
I was super close to the right thing. Honestly, I'm still running into
problems with it. When I just now ran it for the first time today, it blew
up with complaints about not having state locally and asking if I wanted to
refresh from s3. But I sure as heck don't know where my local state went.
And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code, but when I do use that flag, I have to wait
10-20 minutes for provider plugins to download from releases.hashicorp.com.
The problem is most definitely not network - I can pull things from that
host in a heartbeat via a web browser or curl - but something is causing
terraform to take forever when it loads those. As a result, my turnaround
rate is abysmal. Every minor change takes 30 minutes to validate against
AWS.

On Thu, Nov 2, 2017 at 10:09 AM, Yevgeniy Brikman [e-mail]
wrote:

Thanks, the explanation of what is going on with the path lunging was very
helpful. You should write that up somewhere public.

Glad it helped. I added it here: #341
https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is just
a mostly empty pair of repositories but with just enough to demonstrate all
of the common practices - cascading environment, region, and account vars,
etc. basically, exactly the pair of repos I sent last night, plus maybe
something about IAM best practices so that people are doing the right thing
from the start - it can be harder to add that stuff in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture
https://www.gruntwork.io/reference-architecture/ has all of that, and
then some!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341491877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGTMTNYwrH3y0r8Qk2dJ3d1xJSIYks5syfcpgaJpZM4PxXd4
.

[ghost]

And for what it is worth, I did enable the provider cache. It doesn't seem
to have helped at all. I have the cache directory and it has the binaries
in it, but it still downloads all the provider plugins on every run. I'm
assuming this is somehow the --terraform-source-update flag's doing, but I
just get constant errors if I ditch that.

On Thu, Nov 2, 2017 at 1:35 PM, Samuel Gendler [e-mail] wrote:

Yeah, but they actually lack all of the important parts that I was looking
for examples of - they don't demonstrate how to access a module from within
a template since they only use resources directly within the *.tf files,
and they don't show the cascading variable overrides and instead of
including empty directories for _global and region and account layers in
the hierarchy in order to demonstrate the concepts, those dirs are entirely
missing. That stuff took me 2 full days to get working due to a combination
of user error, bugs, and lack of documentation. I found those repos within
my first 20 minutes of exploration and was using them as my model, but I
still couldn't get modules to work from within the modules repo (which
should maybe be called the templates repo in order to avoid a lot of
unnecessary confusion over the difference between templates and modules).
I scoured the internet and your book for examples that combined terragrunt
with the use of modules in a template and they just don't seem to exist,
which is odd, since your reference architecture consists of almost nothing
but that exact pattern, I suspect. What I was looking for was
production-ready example repos that just have a minimum of templates and
configurations but are otherwise production-ready, whereas those really are
just quick examples of very simplistic code organization.

I was basically on the right track from the get go, but kept undoing
progress when bugs/user error would cause my experiments to fail even when
I was super close to the right thing. Honestly, I'm still running into
problems with it. When I just now ran it for the first time today, it blew
up with complaints about not having state locally and asking if I wanted to
refresh from s3. But I sure as heck don't know where my local state went.
And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code, but when I do use that flag, I have to wait
10-20 minutes for provider plugins to download from releases.hashicorp.com.
The problem is most definitely not network - I can pull things from that
host in a heartbeat via a web browser or curl - but something is causing
terraform to take forever when it loads those. As a result, my turnaround
rate is abysmal. Every minor change takes 30 minutes to validate against
AWS.

On Thu, Nov 2, 2017 at 10:09 AM, Yevgeniy Brikman <
[email protected]> wrote:

Thanks, the explanation of what is going on with the path lunging was
very helpful. You should write that up somewhere public.

Glad it helped. I added it here: #341
https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is
just a mostly empty pair of repositories but with just enough to
demonstrate all of the common practices - cascading environment, region,
and account vars, etc. basically, exactly the pair of repos I sent last
night, plus maybe something about IAM best practices so that people are
doing the right thing from the start - it can be harder to add that stuff
in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture
https://www.gruntwork.io/reference-architecture/ has all of that, and
then some!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341491877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGTMTNYwrH3y0r8Qk2dJ3d1xJSIYks5syfcpgaJpZM4PxXd4
.

[ghost]

For what it is worth, I included a perfect cut-and-paste copy of the
example code for the module for adding network ACLs to a mgmt-vpc and when
I ran it once, it creates the resources correctly on the first attempt.
When I applied it again, 2 minutes later, with absolutely no changes to
anything (I was debugging the provider cache thing), it still decided it
needed to kill a bunch of resources and re-create them, and then it exited
with an error about a network association with a particular id not
existing. I was surprised to see it update anything in the first place and
even more surprised to get errors on the second run that I didn't see the
first time. It seems kind of problematic if I cannot update some of the
most foundational pieces of infrastructure in your library... The only
thing I added was the following block to main.tf and copied the 2 outputs
from the 2nd module.

module "mgmt_vpc" {
source = "[email protected]:
gruntwork-io/module-vpc.git//modules/vpc-mgmt?ref=v0.3.1"

vpc_name = "${var.vpc_name}"
aws_region = "${var.aws_region}"
cidr_block = "${var.cidr_block}"
num_availability_zones = "${var.num_availability_zones}"
public_subnet_cidr_blocks = "${var.public_subnet_cidr_blocks}"
private_subnet_cidr_blocks = "${var.private_subnet_cidr_blocks}"
num_nat_gateways = "${var.num_nat_gateways}"
}

module "mgmt_vpc_network_acls" {

• source =
  "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgmt-network-acls?ref=v0.3.1"*

• vpc_id = "${module.mgmt_vpc.vpc_id}"*
• vpc_name = "${module.mgmt_vpc.vpc_name}"*
• vpc_ready = "${module.mgmt_vpc.vpc_ready}"*

• num_subnets = "${module.mgmt_vpc.num_availability_zones}"*

• public_subnet_ids = "${module.mgmt_vpc.public_subnet_ids}"*

• private_subnet_ids = "${module.mgmt_vpc.private_subnet_ids}"*

• public_subnet_cidr_blocks =
  "${module.mgmt_vpc.public_subnet_cidr_blocks}"*

• private_subnet_cidr_blocks =
  "${module.mgmt_vpc.private_subnet_cidr_blocks}"*
  }

The 3rd time I applied it, it corrected the error from the 2nd time. The
4th time I ran it, it once again destroyed all of the public subnets and
recreated them, destroyed the NAT gateway and recreated it (which taks
minutes, not seconds) and then it once again died with the exact same error

• failed to find association for subnet: subnet-xxxxx

Error: Error applying plan:

1 error(s) occurred:

• module.mgmt_vpc_network_acls.aws_network_acl.public_subnets: 1 error(s)
  occurred:

• aws_network_acl.public_subnets: Failed to find acl association: acl
  acl-6d381115 with subnet subnet-a6699989: could not find association for
  subnet: subnet-a6699989

The next time, it once again corrected the problem. So it is very
consistently working correctly every other time, implying some kind of bug
related to state and recognizing what is running versus what is expected to
be running.

So then I removed the 2nd module and the new outputs and tried running it
repeatedly again and got the same result - so the bug seems to be in
vpc-mgmt - it is failing to recognize that the incoming state matches the
expected state so it is making changes on every run even when nothing has
changed. At least without the network acls, it doesn't fail on every other
run, but the acls aren't the cause of the state change on every run. You
already have the code in the repos I sent last night plus the bold block
above. Nothing else has changed.

On Thu, Nov 2, 2017 at 1:49 PM, Samuel Gendler [e-mail] wrote:

And for what it is worth, I did enable the provider cache. It doesn't
seem to have helped at all. I have the cache directory and it has the
binaries in it, but it still downloads all the provider plugins on every
run. I'm assuming this is somehow the --terraform-source-update flag's
doing, but I just get constant errors if I ditch that.

On Thu, Nov 2, 2017 at 1:35 PM, Samuel Gendler [e-mail] wrote:

Yeah, but they actually lack all of the important parts that I was
looking for examples of - they don't demonstrate how to access a module
from within a template since they only use resources directly within the
*.tf files, and they don't show the cascading variable overrides and
instead of including empty directories for _global and region and account
layers in the hierarchy in order to demonstrate the concepts, those dirs
are entirely missing. That stuff took me 2 full days to get working due to
a combination of user error, bugs, and lack of documentation. I found
those repos within my first 20 minutes of exploration and was using them as
my model, but I still couldn't get modules to work from within the modules
repo (which should maybe be called the templates repo in order to avoid a
lot of unnecessary confusion over the difference between templates and
modules). I scoured the internet and your book for examples that combined
terragrunt with the use of modules in a template and they just don't seem
to exist, which is odd, since your reference architecture consists of
almost nothing but that exact pattern, I suspect. What I was looking for
was production-ready example repos that just have a minimum of templates
and configurations but are otherwise production-ready, whereas those really
are just quick examples of very simplistic code organization.

I was basically on the right track from the get go, but kept undoing
progress when bugs/user error would cause my experiments to fail even when
I was super close to the right thing. Honestly, I'm still running into
problems with it. When I just now ran it for the first time today, it blew
up with complaints about not having state locally and asking if I wanted to
refresh from s3. But I sure as heck don't know where my local state went.
And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code, but when I do use that flag, I have to wait
10-20 minutes for provider plugins to download from
releases.hashicorp.com. The problem is most definitely not network - I
can pull things from that host in a heartbeat via a web browser or curl -
but something is causing terraform to take forever when it loads those. As
a result, my turnaround rate is abysmal. Every minor change takes 30
minutes to validate against AWS.

On Thu, Nov 2, 2017 at 10:09 AM, Yevgeniy Brikman <
[email protected]> wrote:

Thanks, the explanation of what is going on with the path lunging was
very helpful. You should write that up somewhere public.

Glad it helped. I added it here: #341
https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is
just a mostly empty pair of repositories but with just enough to
demonstrate all of the common practices - cascading environment, region,
and account vars, etc. basically, exactly the pair of repos I sent last
night, plus maybe something about IAM best practices so that people are
doing the right thing from the start - it can be harder to add that stuff
in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-mo
dules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture
https://www.gruntwork.io/reference-architecture/ has all of that, and
then some!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341491877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGTMTNYwrH3y0r8Qk2dJ3d1xJSIYks5syfcpgaJpZM4PxXd4
.

[ghost]

Here's a log of 2 (out of 3) consecutive runs WITHOUT the network acls -
just the mgmt-vpc. It is succeeding, but it is blowing away a network and
the NAT gateway every single time (and the NAT gateway isn't fast to
restart!).

$ terragrunt apply --terragrunt-source ../../../../../stem-infra//vpc_mgmt/
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:21 Running command: terraform --version
[terragrunt] 2017/11/02 14:09:21 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/02 14:09:21 Cleaning up existing *.tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/02 14:09:21 Downloading Terraform configurations from
file:///Users/sgendler/src/stem/stem-infra into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
using terraform init
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:21 Backend s3 has not changed.
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:22 Running command: terraform init
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
-from-module=file:///Users/sgendler/src/stem/stem-infra
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra"...
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] 2017/11/02 14:09:22 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:09:22 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:09:22 Backend s3 has not changed.
[terragrunt] 2017/11/02 14:09:22 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../../account.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
-lock-timeout=20m
aws_vpc.main: Refreshing state... (ID: vpc-b03e96c8)
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
aws_subnet.private[1]: Refreshing state... (ID: subnet-a8fd4fe3)
aws_subnet.private[0]: Refreshing state... (ID: subnet-77649558)
aws_subnet.private[2]: Refreshing state... (ID: subnet-77678d2a)
aws_route_table.private[2]: Refreshing state... (ID: rtb-a47c32de)
aws_route_table.private[0]: Refreshing state... (ID: rtb-64632d1e)
aws_internet_gateway.main: Refreshing state... (ID: igw-0348f57a)
aws_subnet.public[2]: Refreshing state... (ID: subnet-c86b8195)
aws_route_table.private[1]: Refreshing state... (ID: rtb-07632d7d)
aws_subnet.public[0]: Refreshing state... (ID: subnet-086d9d27)
aws_subnet.public[1]: Refreshing state... (ID: subnet-d9e65492)
aws_route_table.public: Refreshing state... (ID: rtb-2078365a)
aws_vpc_endpoint.s3-private: Refreshing state... (ID: vpce-df3686b6)
aws_eip.nat: Refreshing state... (ID: eipalloc-85c69ab0)
aws_route_table_association.private[1]: Refreshing state... (ID:
rtbassoc-cfd165b2)
aws_route_table_association.private[0]: Refreshing state... (ID:
rtbassoc-ffd56182)
aws_route_table_association.private[2]: Refreshing state... (ID:
rtbassoc-96eb5feb)
aws_route_table_association.public[2]: Refreshing state... (ID:
rtbassoc-62bb0d1f)
aws_route_table_association.public[1]: Refreshing state... (ID:
rtbassoc-2ab40257)
aws_route_table_association.public[0]: Refreshing state... (ID:
rtbassoc-8cb006f1)
aws_vpc_endpoint.s3-public: Refreshing state... (ID: vpce-753e8e1c)
aws_route.internet: Refreshing state... (ID: r-rtb-2078365a1080289494)
aws_nat_gateway.nat: Refreshing state... (ID: nat-025791183dda99bb6)
aws_route.nat[1]: Refreshing state... (ID: r-rtb-07632d7d1080289494)
aws_route.nat[2]: Refreshing state... (ID: r-rtb-a47c32de1080289494)
aws_route.nat[0]: Refreshing state... (ID: r-rtb-64632d1e1080289494)
null_resource.vpc_ready: Refreshing state... (ID: 3854081390465364666)
module.mgmt_vpc.aws_route_table_association.public[0]: Destroying... (ID:
rtbassoc-8cb006f1)
module.mgmt_vpc.aws_route_table_association.public[2]: Destroying... (ID:
rtbassoc-62bb0d1f)
module.mgmt_vpc.aws_nat_gateway.nat: Destroying... (ID:
nat-025791183dda99bb6)
module.mgmt_vpc.aws_route_table_association.public[1]: Destroying... (ID:
rtbassoc-2ab40257)
module.mgmt_vpc.aws_route_table_association.public[2]: Destruction complete
after 0s
module.mgmt_vpc.aws_route_table_association.public[0]: Destruction complete
after 0s
module.mgmt_vpc.aws_route_table_association.public[1]: Destruction complete
after 0s
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Destruction complete after 53s
module.mgmt_vpc.aws_subnet.public[0]: Destroying... (ID: subnet-086d9d27)
module.mgmt_vpc.aws_subnet.public[0]: Destruction complete after 1s
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-6169994e)
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-d9e65492"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-6169994e"
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-6169994e"
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 0s (ID: rtbassoc-33a6104e)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 0s (ID: rtbassoc-8ebc0af3)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 0s (ID: rtbassoc-a9ba0cd4)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 1m43s (ID:
nat-0ec0ce0ca12b73f43)
module.mgmt_vpc.aws_route.nat[1]: Modifying... (ID:
r-rtb-07632d7d1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[0]: Modifying... (ID:
r-rtb-64632d1e1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[2]: Modifying... (ID:
r-rtb-a47c32de1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[1]: Modifications complete after 0s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[2]: Modifications complete after 0s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.aws_route.nat[0]: Modifications complete after 1s (ID:
r-rtb-64632d1e1080289494)

Apply complete! Resources: 5 added, 3 changed, 5 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-6169994e,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666
Samuels-MacBook-Pro:vpc_mgmt sgendler$ terragrunt apply
--terragrunt-source ../../../../../stem-infra//vpc_mgmt/
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:23 Running command: terraform --version
[terragrunt] 2017/11/02 14:14:23 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/02 14:14:23 Cleaning up existing *.tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/02 14:14:23 Downloading Terraform configurations from
file:///Users/sgendler/src/stem/stem-infra into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
using terraform init
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:23 Backend s3 has not changed.
[terragrunt]
[/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:24 Running command: terraform init
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
-from-module=file:///Users/sgendler/src/stem/stem-infra
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra"...
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] 2017/11/02 14:14:24 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:14:24 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:14:24 Backend s3 has not changed.
[terragrunt] 2017/11/02 14:14:24 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../../account.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/terraform.tfvars
-lock-timeout=20m
aws_vpc.main: Refreshing state... (ID: vpc-b03e96c8)
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
aws_internet_gateway.main: Refreshing state... (ID: igw-0348f57a)
aws_route_table.public: Refreshing state... (ID: rtb-2078365a)
aws_subnet.public[2]: Refreshing state... (ID: subnet-c86b8195)
aws_subnet.public[0]: Refreshing state... (ID: subnet-6169994e)
aws_subnet.public[1]: Refreshing state... (ID: subnet-d9e65492)
aws_route_table.private[1]: Refreshing state... (ID: rtb-07632d7d)
aws_route_table.private[0]: Refreshing state... (ID: rtb-64632d1e)
aws_route_table.private[2]: Refreshing state... (ID: rtb-a47c32de)
aws_subnet.private[2]: Refreshing state... (ID: subnet-77678d2a)
aws_subnet.private[0]: Refreshing state... (ID: subnet-77649558)
aws_subnet.private[1]: Refreshing state... (ID: subnet-a8fd4fe3)
aws_eip.nat: Refreshing state... (ID: eipalloc-85c69ab0)
aws_vpc_endpoint.s3-private: Refreshing state... (ID: vpce-df3686b6)
aws_route.internet: Refreshing state... (ID: r-rtb-2078365a1080289494)
aws_route_table_association.public[0]: Refreshing state... (ID:
rtbassoc-8ebc0af3)
aws_route_table_association.public[2]: Refreshing state... (ID:
rtbassoc-33a6104e)
aws_route_table_association.public[1]: Refreshing state... (ID:
rtbassoc-a9ba0cd4)
aws_vpc_endpoint.s3-public: Refreshing state... (ID: vpce-753e8e1c)
aws_nat_gateway.nat: Refreshing state... (ID: nat-0ec0ce0ca12b73f43)
aws_route_table_association.private[1]: Refreshing state... (ID:
rtbassoc-cfd165b2)
aws_route_table_association.private[2]: Refreshing state... (ID:
rtbassoc-96eb5feb)
aws_route_table_association.private[0]: Refreshing state... (ID:
rtbassoc-ffd56182)
aws_route.nat[2]: Refreshing state... (ID: r-rtb-a47c32de1080289494)
aws_route.nat[1]: Refreshing state... (ID: r-rtb-07632d7d1080289494)
aws_route.nat[0]: Refreshing state... (ID: r-rtb-64632d1e1080289494)
null_resource.vpc_ready: Refreshing state... (ID: 3854081390465364666)
module.mgmt_vpc.aws_route_table_association.public[0]: Destroying... (ID:
rtbassoc-8ebc0af3)
module.mgmt_vpc.aws_nat_gateway.nat: Destroying... (ID:
nat-0ec0ce0ca12b73f43)
module.mgmt_vpc.aws_route_table_association.public[2]: Destroying... (ID:
rtbassoc-33a6104e)
module.mgmt_vpc.aws_route_table_association.public[1]: Destroying... (ID:
rtbassoc-a9ba0cd4)
module.mgmt_vpc.aws_route_table_association.public[2]: Destruction complete
after 1s
module.mgmt_vpc.aws_route_table_association.public[1]: Destruction complete
after 1s
module.mgmt_vpc.aws_route_table_association.public[0]: Destruction complete
after 1s
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Destruction complete after 1m20s
module.mgmt_vpc.aws_subnet.public[0]: Destroying... (ID: subnet-6169994e)
module.mgmt_vpc.aws_subnet.public[0]: Destruction complete after 0s
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-366f9f19)
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-366f9f19"
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-d9e65492"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-366f9f19"
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 1s (ID: rtbassoc-8fa016f2)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 1s (ID: rtbassoc-ffb80e82)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 1s (ID: rtbassoc-94a711e9)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (2m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 2m4s (ID:
nat-05f842507e06b84de)
module.mgmt_vpc.aws_route.nat[0]: Modifying... (ID:
r-rtb-64632d1e1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[2]: Modifying... (ID:
r-rtb-a47c32de1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[1]: Modifying... (ID:
r-rtb-07632d7d1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[2]: Modifications complete after 1s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.aws_route.nat[1]: Modifications complete after 1s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[0]: Modifications complete after 1s (ID:
r-rtb-64632d1e1080289494)

Apply complete! Resources: 5 added, 3 changed, 5 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-366f9f19,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

And here is the terragrunt plan output:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ module.mgmt_vpc.aws_nat_gateway.nat (new resource required)
id: "nat-05f842507e06b84de" =>
(forces new resource)
allocation_id: "eipalloc-85c69ab0" =>
"eipalloc-85c69ab0"
network_interface_id: "eni-704402fd" =>
private_ip: "10.0.3.224" =>
public_ip: "34.237.252.19" =>
subnet_id: "subnet-366f9f19" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

~ module.mgmt_vpc.aws_route.nat[0]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

~ module.mgmt_vpc.aws_route.nat[1]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

~ module.mgmt_vpc.aws_route.nat[2]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

-/+ module.mgmt_vpc.aws_route_table_association.public[0] (new resource
required)
id: "rtbassoc-ffb80e82" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-366f9f19" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_route_table_association.public[1] (new resource
required)
id: "rtbassoc-94a711e9" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-d9e65492" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_route_table_association.public[2] (new resource
required)
id: "rtbassoc-8fa016f2" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-c86b8195" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_subnet.public[0] (new resource required)
id: "subnet-366f9f19" =>
(forces new resource)
assign_ipv6_address_on_creation: "false" => "false"
availability_zone: "us-east-1a" => "us-east-1a"
cidr_block: "10.0.0.0/22" => "10.0.1.0/22"
(forces new resource)
ipv6_cidr_block: "" =>
ipv6_cidr_block_association_id: "" =>
map_public_ip_on_launch: "false" => "false"
tags.%: "1" => "1"
tags.Name: "mgmt-public-0" => "mgmt-public-0"
vpc_id: "vpc-b03e96c8" => "vpc-b03e96c8"

Plan: 5 to add, 3 to change, 5 to destroy.

---

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Releasing state lock. This may take a few moments...

On Thu, Nov 2, 2017 at 2:14 PM, Samuel Gendler [e-mail] wrote:

For what it is worth, I included a perfect cut-and-paste copy of the
example code for the module for adding network ACLs to a mgmt-vpc and when
I ran it once, it creates the resources correctly on the first attempt.
When I applied it again, 2 minutes later, with absolutely no changes to
anything (I was debugging the provider cache thing), it still decided it
needed to kill a bunch of resources and re-create them, and then it exited
with an error about a network association with a particular id not
existing. I was surprised to see it update anything in the first place and
even more surprised to get errors on the second run that I didn't see the
first time. It seems kind of problematic if I cannot update some of the
most foundational pieces of infrastructure in your library... The only
thing I added was the following block to main.tf and copied the 2 outputs
from the 2nd module.

module "mgmt_vpc" {
source = "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-
mgmt?ref=v0.3.1"

vpc_name = "${var.vpc_name}"
aws_region = "${var.aws_region}"
cidr_block = "${var.cidr_block}"
num_availability_zones = "${var.num_availability_zones}"
public_subnet_cidr_blocks = "${var.public_subnet_cidr_blocks}"
private_subnet_cidr_blocks = "${var.private_subnet_cidr_blocks}"
num_nat_gateways = "${var.num_nat_gateways}"
}

module "mgmt_vpc_network_acls" {

• source =
  "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgmt-network-acls?ref=v0.3.1"*

• vpc_id = "${module.mgmt_vpc.vpc_id}"*
• vpc_name = "${module.mgmt_vpc.vpc_name}"*
• vpc_ready = "${module.mgmt_vpc.vpc_ready}"*

• num_subnets = "${module.mgmt_vpc.num_availability_zones}"*

• public_subnet_ids = "${module.mgmt_vpc.public_subnet_ids}"*

• private_subnet_ids = "${module.mgmt_vpc.private_subnet_ids}"*

• public_subnet_cidr_blocks =
  "${module.mgmt_vpc.public_subnet_cidr_blocks}"*

• private_subnet_cidr_blocks =
  "${module.mgmt_vpc.private_subnet_cidr_blocks}"*
  }

The 3rd time I applied it, it corrected the error from the 2nd time. The
4th time I ran it, it once again destroyed all of the public subnets and
recreated them, destroyed the NAT gateway and recreated it (which taks
minutes, not seconds) and then it once again died with the exact same error

• failed to find association for subnet: subnet-xxxxx

Error: Error applying plan:

1 error(s) occurred:

• module.mgmt_vpc_network_acls.aws_network_acl.public_subnets: 1 error(s)
  occurred:

• aws_network_acl.public_subnets: Failed to find acl association: acl
  acl-6d381115 with subnet subnet-a6699989: could not find association for
  subnet: subnet-a6699989

The next time, it once again corrected the problem. So it is very
consistently working correctly every other time, implying some kind of bug
related to state and recognizing what is running versus what is expected to
be running.

So then I removed the 2nd module and the new outputs and tried running it
repeatedly again and got the same result - so the bug seems to be in
vpc-mgmt - it is failing to recognize that the incoming state matches the
expected state so it is making changes on every run even when nothing has
changed. At least without the network acls, it doesn't fail on every other
run, but the acls aren't the cause of the state change on every run. You
already have the code in the repos I sent last night plus the bold block
above. Nothing else has changed.

On Thu, Nov 2, 2017 at 1:49 PM, Samuel Gendler [e-mail] wrote:

And for what it is worth, I did enable the provider cache. It doesn't
seem to have helped at all. I have the cache directory and it has the
binaries in it, but it still downloads all the provider plugins on every
run. I'm assuming this is somehow the --terraform-source-update flag's
doing, but I just get constant errors if I ditch that.

On Thu, Nov 2, 2017 at 1:35 PM, Samuel Gendler [e-mail] wrote:

Yeah, but they actually lack all of the important parts that I was
looking for examples of - they don't demonstrate how to access a module
from within a template since they only use resources directly within the
*.tf files, and they don't show the cascading variable overrides and
instead of including empty directories for _global and region and account
layers in the hierarchy in order to demonstrate the concepts, those dirs
are entirely missing. That stuff took me 2 full days to get working due to
a combination of user error, bugs, and lack of documentation. I found
those repos within my first 20 minutes of exploration and was using them as
my model, but I still couldn't get modules to work from within the modules
repo (which should maybe be called the templates repo in order to avoid a
lot of unnecessary confusion over the difference between templates and
modules). I scoured the internet and your book for examples that combined
terragrunt with the use of modules in a template and they just don't seem
to exist, which is odd, since your reference architecture consists of
almost nothing but that exact pattern, I suspect. What I was looking for
was production-ready example repos that just have a minimum of templates
and configurations but are otherwise production-ready, whereas those really
are just quick examples of very simplistic code organization.

I was basically on the right track from the get go, but kept undoing
progress when bugs/user error would cause my experiments to fail even when
I was super close to the right thing. Honestly, I'm still running into
problems with it. When I just now ran it for the first time today, it blew
up with complaints about not having state locally and asking if I wanted to
refresh from s3. But I sure as heck don't know where my local state went.
And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code, but when I do use that flag, I have to wait
10-20 minutes for provider plugins to download from
releases.hashicorp.com. The problem is most definitely not network - I
can pull things from that host in a heartbeat via a web browser or curl -
but something is causing terraform to take forever when it loads those. As
a result, my turnaround rate is abysmal. Every minor change takes 30
minutes to validate against AWS.

On Thu, Nov 2, 2017 at 10:09 AM, Yevgeniy Brikman <
[email protected]> wrote:

Thanks, the explanation of what is going on with the path lunging was
very helpful. You should write that up somewhere public.

Glad it helped. I added it here: #341
https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is
just a mostly empty pair of repositories but with just enough to
demonstrate all of the common practices - cascading environment, region,
and account vars, etc. basically, exactly the pair of repos I sent last
night, plus maybe something about IAM best practices so that people are
doing the right thing from the start - it can be harder to add that stuff
in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-mo
dules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture
https://www.gruntwork.io/reference-architecture/ has all of that,
and then some!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341491877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGTMTNYwrH3y0r8Qk2dJ3d1xJSIYks5syfcpgaJpZM4PxXd4
.

[ghost]

Here's the output of terragrunt show, as well as a screenshot of my
existing NAT gateways - The one that shows up in the plan is the SECOND TO
LAST gateway when sorted by start time. So the new id is not getting
written into the state after it is created, which is subsequently causing
the next run to decide that it needs to get created again, and then it once
again is out of date, since the state gets updated with the id of the one
that was killed rather than the one that was started. Seems more likely to
be a terraform bug than terragrunt, but I'm hoping you guys have
encountered the problem before, since I am using your modules to
instantiate the infrastructure.

[terragrunt] 2017/11/02 14:35:22 Running command: terraform show

module.mgmt_vpc.aws_eip.nat:
id = eipalloc-85c69ab0
association_id = eipassoc-d37d87e5
domain = vpc
instance =
network_interface = eni-bf367032
private_ip = 10.0.0.229
public_ip = 34.237.252.19
vpc = true
module.mgmt_vpc.aws_internet_gateway.main:
id = igw-0348f57a
tags.% = 1
tags.Name = mgmt
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_nat_gateway.nat:
id = nat-05f842507e06b84de
allocation_id = eipalloc-85c69ab0
network_interface_id = eni-704402fd
private_ip = 10.0.3.224
public_ip = 34.237.252.19
subnet_id = subnet-366f9f19
tags.% = 0
module.mgmt_vpc.aws_route.internet:
id = r-rtb-2078365a1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id = igw-0348f57a
instance_id =
instance_owner_id =
nat_gateway_id =
network_interface_id =
origin = CreateRoute
route_table_id = rtb-2078365a
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route.nat.0:
id = r-rtb-64632d1e1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id =
instance_id =
instance_owner_id =
nat_gateway_id = nat-05f842507e06b84de
network_interface_id =
origin = CreateRoute
route_table_id = rtb-64632d1e
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route.nat.1:
id = r-rtb-07632d7d1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id =
instance_id =
instance_owner_id =
nat_gateway_id = nat-05f842507e06b84de
network_interface_id =
origin = CreateRoute
route_table_id = rtb-07632d7d
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route.nat.2:
id = r-rtb-a47c32de1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id =
instance_id =
instance_owner_id =
nat_gateway_id = nat-05f842507e06b84de
network_interface_id =
origin = CreateRoute
route_table_id = rtb-a47c32de
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route_table.private.0:
id = rtb-64632d1e
propagating_vgws.# = 0
route.# = 1
route.2946293433.cidr_block = 0.0.0.0/0
route.2946293433.egress_only_gateway_id =
route.2946293433.gateway_id =
route.2946293433.instance_id =
route.2946293433.ipv6_cidr_block =
route.2946293433.nat_gateway_id = nat-0ec0ce0ca12b73f43
route.2946293433.network_interface_id =
route.2946293433.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-private-0
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table.private.1:
id = rtb-07632d7d
propagating_vgws.# = 0
route.# = 1
route.2946293433.cidr_block = 0.0.0.0/0
route.2946293433.egress_only_gateway_id =
route.2946293433.gateway_id =
route.2946293433.instance_id =
route.2946293433.ipv6_cidr_block =
route.2946293433.nat_gateway_id = nat-0ec0ce0ca12b73f43
route.2946293433.network_interface_id =
route.2946293433.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-private-1
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table.private.2:
id = rtb-a47c32de
propagating_vgws.# = 0
route.# = 1
route.2946293433.cidr_block = 0.0.0.0/0
route.2946293433.egress_only_gateway_id =
route.2946293433.gateway_id =
route.2946293433.instance_id =
route.2946293433.ipv6_cidr_block =
route.2946293433.nat_gateway_id = nat-0ec0ce0ca12b73f43
route.2946293433.network_interface_id =
route.2946293433.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-private-2
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table.public:
id = rtb-2078365a
propagating_vgws.# = 0
route.# = 1
route.342141474.cidr_block = 0.0.0.0/0
route.342141474.egress_only_gateway_id =
route.342141474.gateway_id = igw-0348f57a
route.342141474.instance_id =
route.342141474.ipv6_cidr_block =
route.342141474.nat_gateway_id =
route.342141474.network_interface_id =
route.342141474.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-public
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table_association.private.0:
id = rtbassoc-ffd56182
route_table_id = rtb-64632d1e
subnet_id = subnet-77649558
module.mgmt_vpc.aws_route_table_association.private.1:
id = rtbassoc-cfd165b2
route_table_id = rtb-07632d7d
subnet_id = subnet-a8fd4fe3
module.mgmt_vpc.aws_route_table_association.private.2:
id = rtbassoc-96eb5feb
route_table_id = rtb-a47c32de
subnet_id = subnet-77678d2a
module.mgmt_vpc.aws_route_table_association.public.0:
id = rtbassoc-ffb80e82
route_table_id = rtb-2078365a
subnet_id = subnet-366f9f19
module.mgmt_vpc.aws_route_table_association.public.1:
id = rtbassoc-94a711e9
route_table_id = rtb-2078365a
subnet_id = subnet-d9e65492
module.mgmt_vpc.aws_route_table_association.public.2:
id = rtbassoc-8fa016f2
route_table_id = rtb-2078365a
subnet_id = subnet-c86b8195
module.mgmt_vpc.aws_subnet.private.0:
id = subnet-77649558
assign_ipv6_address_on_creation = false
availability_zone = us-east-1a
cidr_block = 10.0.100.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-private-0
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.private.1:
id = subnet-a8fd4fe3
assign_ipv6_address_on_creation = false
availability_zone = us-east-1b
cidr_block = 10.0.112.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-private-1
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.private.2:
id = subnet-77678d2a
assign_ipv6_address_on_creation = false
availability_zone = us-east-1c
cidr_block = 10.0.120.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-private-2
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.public.0:
id = subnet-366f9f19
assign_ipv6_address_on_creation = false
availability_zone = us-east-1a
cidr_block = 10.0.0.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-public-0
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.public.1:
id = subnet-d9e65492
assign_ipv6_address_on_creation = false
availability_zone = us-east-1b
cidr_block = 10.0.12.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-public-1
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.public.2:
id = subnet-c86b8195
assign_ipv6_address_on_creation = false
availability_zone = us-east-1c
cidr_block = 10.0.20.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-public-2
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_vpc.main:
id = vpc-b03e96c8
assign_generated_ipv6_cidr_block = false
cidr_block = 10.0.0.0/16
default_network_acl_id = acl-cdbc93b5
default_route_table_id = rtb-c17836bb
default_security_group_id = sg-3a6f4748
dhcp_options_id = dopt-5f48ea26
enable_classiclink = false
enable_classiclink_dns_support = false
enable_dns_hostnames = true
enable_dns_support = true
instance_tenancy = default
main_route_table_id = rtb-c17836bb
tags.% = 1
tags.Name = mgmt
module.mgmt_vpc.aws_vpc_endpoint.s3-private:
id = vpce-df3686b6
cidr_blocks.# = 2
cidr_blocks.0 = 54.231.0.0/17
cidr_blocks.1 = 52.216.0.0/15
policy =
{"Statement":[{"Action":"","Effect":"Allow","Principal":"","Resource":""}],"Version":"2008-10-17"}
prefix_list_id = pl-63a5400a
route_table_ids.# = 3
route_table_ids.1216147752 = rtb-07632d7d
route_table_ids.2661709090 = rtb-64632d1e
route_table_ids.625676261 = rtb-a47c32de
service_name = com.amazonaws.us-east-1.s3
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_vpc_endpoint.s3-public:
id = vpce-753e8e1c
cidr_blocks.# = 2
cidr_blocks.0 = 54.231.0.0/17
cidr_blocks.1 = 52.216.0.0/15
policy =
{"Statement":[{"Action":"","Effect":"Allow","Principal":"","Resource":""}],"Version":"2008-10-17"}
prefix_list_id = pl-63a5400a
route_table_ids.# = 1
route_table_ids.3869909465 = rtb-2078365a
service_name = com.amazonaws.us-east-1.s3
vpc_id = vpc-b03e96c8
module.mgmt_vpc.data.aws_availability_zones.available:
id = 2017-11-02 21:14:31.083538555 +0000 UTC
names.# = 6
names.0 = us-east-1a
names.1 = us-east-1b
names.2 = us-east-1c
names.3 = us-east-1d
names.4 = us-east-1e
names.5 = us-east-1f
module.mgmt_vpc.data.template_file.num_availability_zones:
id = 4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce
rendered = 3
template = 3
module.mgmt_vpc.null_resource.vpc_ready:
id = 3854081390465364666

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-366f9f19,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

On Thu, Nov 2, 2017 at 2:24 PM, Samuel Gendler [e-mail] wrote:

Here's a log of 2 (out of 3) consecutive runs WITHOUT the network acls -
just the mgmt-vpc. It is succeeding, but it is blowing away a network and
the NAT gateway every single time (and the NAT gateway isn't fast to
restart!).

$ terragrunt apply --terragrunt-source ../../../../../stem-infra//
vpc_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:21 Running command: terraform --version
[terragrunt] 2017/11/02 14:09:21 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/
vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/02 14:09:21 Cleaning up existing *.tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/02 14:09:21 Downloading Terraform configurations from
file:///Users/sgendler/src/stem/stem-infra into /var/folders/xr/
t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
using terraform init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:21 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:22 Running command: terraform init
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
-from-module=file:///Users/sgendler/src/stem/stem-infra /var/folders/xr/
t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/
N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra"...
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] 2017/11/02 14:09:22 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:09:22 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:09:22 Backend s3 has not changed.
[terragrunt] 2017/11/02 14:09:22 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/../../../account.tfvars -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/terraform.tfvars -lock-timeout=20m
aws_vpc.main: Refreshing state... (ID: vpc-b03e96c8)
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
aws_subnet.private[1]: Refreshing state... (ID: subnet-a8fd4fe3)
aws_subnet.private[0]: Refreshing state... (ID: subnet-77649558)
aws_subnet.private[2]: Refreshing state... (ID: subnet-77678d2a)
aws_route_table.private[2]: Refreshing state... (ID: rtb-a47c32de)
aws_route_table.private[0]: Refreshing state... (ID: rtb-64632d1e)
aws_internet_gateway.main: Refreshing state... (ID: igw-0348f57a)
aws_subnet.public[2]: Refreshing state... (ID: subnet-c86b8195)
aws_route_table.private[1]: Refreshing state... (ID: rtb-07632d7d)
aws_subnet.public[0]: Refreshing state... (ID: subnet-086d9d27)
aws_subnet.public[1]: Refreshing state... (ID: subnet-d9e65492)
aws_route_table.public: Refreshing state... (ID: rtb-2078365a)
aws_vpc_endpoint.s3-private: Refreshing state... (ID: vpce-df3686b6)
aws_eip.nat: Refreshing state... (ID: eipalloc-85c69ab0)
aws_route_table_association.private[1]: Refreshing state... (ID:
rtbassoc-cfd165b2)
aws_route_table_association.private[0]: Refreshing state... (ID:
rtbassoc-ffd56182)
aws_route_table_association.private[2]: Refreshing state... (ID:
rtbassoc-96eb5feb)
aws_route_table_association.public[2]: Refreshing state... (ID:
rtbassoc-62bb0d1f)
aws_route_table_association.public[1]: Refreshing state... (ID:
rtbassoc-2ab40257)
aws_route_table_association.public[0]: Refreshing state... (ID:
rtbassoc-8cb006f1)
aws_vpc_endpoint.s3-public: Refreshing state... (ID: vpce-753e8e1c)
aws_route.internet: Refreshing state... (ID: r-rtb-2078365a1080289494)
aws_nat_gateway.nat: Refreshing state... (ID: nat-025791183dda99bb6)
aws_route.nat[1]: Refreshing state... (ID: r-rtb-07632d7d1080289494)
aws_route.nat[2]: Refreshing state... (ID: r-rtb-a47c32de1080289494)
aws_route.nat[0]: Refreshing state... (ID: r-rtb-64632d1e1080289494)
null_resource.vpc_ready: Refreshing state... (ID: 3854081390465364666)
module.mgmt_vpc.aws_route_table_association.public[0]: Destroying... (ID:
rtbassoc-8cb006f1)
module.mgmt_vpc.aws_route_table_association.public[2]: Destroying... (ID:
rtbassoc-62bb0d1f)
module.mgmt_vpc.aws_nat_gateway.nat: Destroying... (ID:
nat-025791183dda99bb6)
module.mgmt_vpc.aws_route_table_association.public[1]: Destroying... (ID:
rtbassoc-2ab40257)
module.mgmt_vpc.aws_route_table_association.public[2]: Destruction
complete after 0s
module.mgmt_vpc.aws_route_table_association.public[0]: Destruction
complete after 0s
module.mgmt_vpc.aws_route_table_association.public[1]: Destruction
complete after 0s
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Destruction complete after 53s
module.mgmt_vpc.aws_subnet.public[0]: Destroying... (ID: subnet-086d9d27)
module.mgmt_vpc.aws_subnet.public[0]: Destruction complete after 1s
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-6169994e)
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-d9e65492"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-6169994e"
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-6169994e"
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 0s (ID: rtbassoc-33a6104e)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 0s (ID: rtbassoc-8ebc0af3)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 0s (ID: rtbassoc-a9ba0cd4)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 1m43s (ID:
nat-0ec0ce0ca12b73f43)
module.mgmt_vpc.aws_route.nat[1]: Modifying... (ID:
r-rtb-07632d7d1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[0]: Modifying... (ID:
r-rtb-64632d1e1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[2]: Modifying... (ID:
r-rtb-a47c32de1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[1]: Modifications complete after 0s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[2]: Modifications complete after 0s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.aws_route.nat[0]: Modifications complete after 1s (ID:
r-rtb-64632d1e1080289494)

Apply complete! Resources: 5 added, 3 changed, 5 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-6169994e,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666
Samuels-MacBook-Pro:vpc_mgmt sgendler$ terragrunt apply
--terragrunt-source ../../../../../stem-infra//vpc_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:23 Running command: terraform --version
[terragrunt] 2017/11/02 14:14:23 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/
vpc_mgmt/terraform.tfvars
[terragrunt] 2017/11/02 14:14:23 Cleaning up existing *.tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/02 14:14:23 Downloading Terraform configurations from
file:///Users/sgendler/src/stem/stem-infra into /var/folders/xr/
t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
using terraform init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:23 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:24 Running command: terraform init
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
-from-module=file:///Users/sgendler/src/stem/stem-infra /var/folders/xr/
t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_rVrVmzIDHkzOu35z2CQn0/
N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/stem/stem-infra"...
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] 2017/11/02 14:14:24 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:14:24 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/1-Fiw_
rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:14:24 Backend s3 has not changed.
[terragrunt] 2017/11/02 14:14:24 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/../../../account.tfvars -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/terraform.tfvars -lock-timeout=20m
aws_vpc.main: Refreshing state... (ID: vpc-b03e96c8)
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
aws_internet_gateway.main: Refreshing state... (ID: igw-0348f57a)
aws_route_table.public: Refreshing state... (ID: rtb-2078365a)
aws_subnet.public[2]: Refreshing state... (ID: subnet-c86b8195)
aws_subnet.public[0]: Refreshing state... (ID: subnet-6169994e)
aws_subnet.public[1]: Refreshing state... (ID: subnet-d9e65492)
aws_route_table.private[1]: Refreshing state... (ID: rtb-07632d7d)
aws_route_table.private[0]: Refreshing state... (ID: rtb-64632d1e)
aws_route_table.private[2]: Refreshing state... (ID: rtb-a47c32de)
aws_subnet.private[2]: Refreshing state... (ID: subnet-77678d2a)
aws_subnet.private[0]: Refreshing state... (ID: subnet-77649558)
aws_subnet.private[1]: Refreshing state... (ID: subnet-a8fd4fe3)
aws_eip.nat: Refreshing state... (ID: eipalloc-85c69ab0)
aws_vpc_endpoint.s3-private: Refreshing state... (ID: vpce-df3686b6)
aws_route.internet: Refreshing state... (ID: r-rtb-2078365a1080289494)
aws_route_table_association.public[0]: Refreshing state... (ID:
rtbassoc-8ebc0af3)
aws_route_table_association.public[2]: Refreshing state... (ID:
rtbassoc-33a6104e)
aws_route_table_association.public[1]: Refreshing state... (ID:
rtbassoc-a9ba0cd4)
aws_vpc_endpoint.s3-public: Refreshing state... (ID: vpce-753e8e1c)
aws_nat_gateway.nat: Refreshing state... (ID: nat-0ec0ce0ca12b73f43)
aws_route_table_association.private[1]: Refreshing state... (ID:
rtbassoc-cfd165b2)
aws_route_table_association.private[2]: Refreshing state... (ID:
rtbassoc-96eb5feb)
aws_route_table_association.private[0]: Refreshing state... (ID:
rtbassoc-ffd56182)
aws_route.nat[2]: Refreshing state... (ID: r-rtb-a47c32de1080289494)
aws_route.nat[1]: Refreshing state... (ID: r-rtb-07632d7d1080289494)
aws_route.nat[0]: Refreshing state... (ID: r-rtb-64632d1e1080289494)
null_resource.vpc_ready: Refreshing state... (ID: 3854081390465364666)
module.mgmt_vpc.aws_route_table_association.public[0]: Destroying... (ID:
rtbassoc-8ebc0af3)
module.mgmt_vpc.aws_nat_gateway.nat: Destroying... (ID:
nat-0ec0ce0ca12b73f43)
module.mgmt_vpc.aws_route_table_association.public[2]: Destroying... (ID:
rtbassoc-33a6104e)
module.mgmt_vpc.aws_route_table_association.public[1]: Destroying... (ID:
rtbassoc-a9ba0cd4)
module.mgmt_vpc.aws_route_table_association.public[2]: Destruction
complete after 1s
module.mgmt_vpc.aws_route_table_association.public[1]: Destruction
complete after 1s
module.mgmt_vpc.aws_route_table_association.public[0]: Destruction
complete after 1s
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Destruction complete after 1m20s
module.mgmt_vpc.aws_subnet.public[0]: Destroying... (ID: subnet-6169994e)
module.mgmt_vpc.aws_subnet.public[0]: Destruction complete after 0s
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-366f9f19)
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-366f9f19"
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-d9e65492"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-366f9f19"
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 1s (ID: rtbassoc-8fa016f2)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 1s (ID: rtbassoc-ffb80e82)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 1s (ID: rtbassoc-94a711e9)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (2m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 2m4s (ID:
nat-05f842507e06b84de)
module.mgmt_vpc.aws_route.nat[0]: Modifying... (ID:
r-rtb-64632d1e1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[2]: Modifying... (ID:
r-rtb-a47c32de1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[1]: Modifying... (ID:
r-rtb-07632d7d1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[2]: Modifications complete after 1s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.aws_route.nat[1]: Modifications complete after 1s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[0]: Modifications complete after 1s (ID:
r-rtb-64632d1e1080289494)

Apply complete! Resources: 5 added, 3 changed, 5 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-366f9f19,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

And here is the terragrunt plan output:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ module.mgmt_vpc.aws_nat_gateway.nat (new resource required)
id: "nat-05f842507e06b84de" =>
(forces new resource)
allocation_id: "eipalloc-85c69ab0" =>
"eipalloc-85c69ab0"
network_interface_id: "eni-704402fd" =>
private_ip: "10.0.3.224" =>
public_ip: "34.237.252.19" =>
subnet_id: "subnet-366f9f19" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

~ module.mgmt_vpc.aws_route.nat[0]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

~ module.mgmt_vpc.aws_route.nat[1]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

~ module.mgmt_vpc.aws_route.nat[2]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

-/+ module.mgmt_vpc.aws_route_table_association.public[0] (new resource
required)
id: "rtbassoc-ffb80e82" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-366f9f19" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_route_table_association.public[1] (new resource
required)
id: "rtbassoc-94a711e9" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-d9e65492" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_route_table_association.public[2] (new resource
required)
id: "rtbassoc-8fa016f2" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-c86b8195" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_subnet.public[0] (new resource required)
id: "subnet-366f9f19" =>
(forces new resource)
assign_ipv6_address_on_creation: "false" => "false"
availability_zone: "us-east-1a" => "us-east-1a"
cidr_block: "10.0.0.0/22" => "10.0.1.0/22"
(forces new resource)
ipv6_cidr_block: "" =>
ipv6_cidr_block_association_id: "" =>
map_public_ip_on_launch: "false" => "false"
tags.%: "1" => "1"
tags.Name: "mgmt-public-0" => "mgmt-public-0"
vpc_id: "vpc-b03e96c8" => "vpc-b03e96c8"

Plan: 5 to add, 3 to change, 5 to destroy.

---

Note: You didn't specify an "-out" parameter to save this plan, so
Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Releasing state lock. This may take a few moments...

On Thu, Nov 2, 2017 at 2:14 PM, Samuel Gendler [e-mail] wrote:

For what it is worth, I included a perfect cut-and-paste copy of the
example code for the module for adding network ACLs to a mgmt-vpc and when
I ran it once, it creates the resources correctly on the first attempt.
When I applied it again, 2 minutes later, with absolutely no changes to
anything (I was debugging the provider cache thing), it still decided it
needed to kill a bunch of resources and re-create them, and then it exited
with an error about a network association with a particular id not
existing. I was surprised to see it update anything in the first place and
even more surprised to get errors on the second run that I didn't see the
first time. It seems kind of problematic if I cannot update some of the
most foundational pieces of infrastructure in your library... The only
thing I added was the following block to main.tf and copied the 2
outputs from the 2nd module.

module "mgmt_vpc" {
source = "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgm
t?ref=v0.3.1"

vpc_name = "${var.vpc_name}"
aws_region = "${var.aws_region}"
cidr_block = "${var.cidr_block}"
num_availability_zones = "${var.num_availability_zones}"
public_subnet_cidr_blocks = "${var.public_subnet_cidr_blocks}"
private_subnet_cidr_blocks = "${var.private_subnet_cidr_blocks}"
num_nat_gateways = "${var.num_nat_gateways}"
}

module "mgmt_vpc_network_acls" {

• source =
  "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgmt-network-acls?ref=v0.3.1"*

• vpc_id = "${module.mgmt_vpc.vpc_id}"*
• vpc_name = "${module.mgmt_vpc.vpc_name}"*
• vpc_ready = "${module.mgmt_vpc.vpc_ready}"*

• num_subnets = "${module.mgmt_vpc.num_availability_zones}"*

• public_subnet_ids = "${module.mgmt_vpc.public_subnet_ids}"*

• private_subnet_ids = "${module.mgmt_vpc.private_subnet_ids}"*

• public_subnet_cidr_blocks =
  "${module.mgmt_vpc.public_subnet_cidr_blocks}"*

• private_subnet_cidr_blocks =
  "${module.mgmt_vpc.private_subnet_cidr_blocks}"*
  }

The 3rd time I applied it, it corrected the error from the 2nd time. The
4th time I ran it, it once again destroyed all of the public subnets and
recreated them, destroyed the NAT gateway and recreated it (which taks
minutes, not seconds) and then it once again died with the exact same error

• failed to find association for subnet: subnet-xxxxx

Error: Error applying plan:

1 error(s) occurred:

• module.mgmt_vpc_network_acls.aws_network_acl.public_subnets: 1
  error(s) occurred:

• aws_network_acl.public_subnets: Failed to find acl association: acl
  acl-6d381115 with subnet subnet-a6699989: could not find association for
  subnet: subnet-a6699989

The next time, it once again corrected the problem. So it is very
consistently working correctly every other time, implying some kind of bug
related to state and recognizing what is running versus what is expected to
be running.

So then I removed the 2nd module and the new outputs and tried running it
repeatedly again and got the same result - so the bug seems to be in
vpc-mgmt - it is failing to recognize that the incoming state matches the
expected state so it is making changes on every run even when nothing has
changed. At least without the network acls, it doesn't fail on every other
run, but the acls aren't the cause of the state change on every run. You
already have the code in the repos I sent last night plus the bold block
above. Nothing else has changed.

On Thu, Nov 2, 2017 at 1:49 PM, Samuel Gendler [e-mail] wrote:

And for what it is worth, I did enable the provider cache. It doesn't
seem to have helped at all. I have the cache directory and it has the
binaries in it, but it still downloads all the provider plugins on every
run. I'm assuming this is somehow the --terraform-source-update flag's
doing, but I just get constant errors if I ditch that.

On Thu, Nov 2, 2017 at 1:35 PM, Samuel Gendler [e-mail] wrote:

Yeah, but they actually lack all of the important parts that I was
looking for examples of - they don't demonstrate how to access a module
from within a template since they only use resources directly within the
*.tf files, and they don't show the cascading variable overrides and
instead of including empty directories for _global and region and account
layers in the hierarchy in order to demonstrate the concepts, those dirs
are entirely missing. That stuff took me 2 full days to get working due to
a combination of user error, bugs, and lack of documentation. I found
those repos within my first 20 minutes of exploration and was using them as
my model, but I still couldn't get modules to work from within the modules
repo (which should maybe be called the templates repo in order to avoid a
lot of unnecessary confusion over the difference between templates and
modules). I scoured the internet and your book for examples that combined
terragrunt with the use of modules in a template and they just don't seem
to exist, which is odd, since your reference architecture consists of
almost nothing but that exact pattern, I suspect. What I was looking for
was production-ready example repos that just have a minimum of templates
and configurations but are otherwise production-ready, whereas those really
are just quick examples of very simplistic code organization.

I was basically on the right track from the get go, but kept undoing
progress when bugs/user error would cause my experiments to fail even when
I was super close to the right thing. Honestly, I'm still running into
problems with it. When I just now ran it for the first time today, it blew
up with complaints about not having state locally and asking if I wanted to
refresh from s3. But I sure as heck don't know where my local state went.
And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code, but when I do use that flag, I have to wait
10-20 minutes for provider plugins to download from
releases.hashicorp.com. The problem is most definitely not network -
I can pull things from that host in a heartbeat via a web browser or curl -
but something is causing terraform to take forever when it loads those. As
a result, my turnaround rate is abysmal. Every minor change takes 30
minutes to validate against AWS.

On Thu, Nov 2, 2017 at 10:09 AM, Yevgeniy Brikman <
[email protected]> wrote:

Thanks, the explanation of what is going on with the path lunging was
very helpful. You should write that up somewhere public.

Glad it helped. I added it here: #341
https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is
just a mostly empty pair of repositories but with just enough to
demonstrate all of the common practices - cascading environment, region,
and account vars, etc. basically, exactly the pair of repos I sent last
night, plus maybe something about IAM best practices so that people are
doing the right thing from the start - it can be harder to add that stuff
in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
https://github.com/gruntwork-io/terragrunt-infrastructure-mo
dules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture
https://www.gruntwork.io/reference-architecture/ has all of that,
and then some!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341491877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGTMTNYwrH3y0r8Qk2dJ3d1xJSIYks5syfcpgaJpZM4PxXd4
.

[ghost]

I suspect the problem is that the nat_gateway_id variable in aws_route is
not conditional on the number of NAT gateways. It assumes that there is
one nat gateway per availability zone, but it is possible to set the number
of gateways to a different number. I'm not really sure how to solve that
one, though if you assume it is either 1 or num_availability_zones, it can
be solved with a simple conditional. If someone sets it to a value greater
than 1 but less than num_availability_zones, things are going to be much
more complicated (and probably not what was ever intended).

Follow-on question - If I want to copy your module code into my templates
repo until you can patch it, where do I put it? I can figure it out from
the docs, but I've had such a hard time with trial and error coding and
terragrunt and terraform so far that I figure it is wise to ask and
shortcut some of that process.

--sam

On Thu, Nov 2, 2017 at 2:41 PM, Samuel Gendler [e-mail] wrote:

Here's the output of terragrunt show, as well as a screenshot of my
existing NAT gateways - The one that shows up in the plan is the SECOND TO
LAST gateway when sorted by start time. So the new id is not getting
written into the state after it is created, which is subsequently causing
the next run to decide that it needs to get created again, and then it once
again is out of date, since the state gets updated with the id of the one
that was killed rather than the one that was started. Seems more likely to
be a terraform bug than terragrunt, but I'm hoping you guys have
encountered the problem before, since I am using your modules to
instantiate the infrastructure.

[terragrunt] 2017/11/02 14:35:22 Running command: terraform show

module.mgmt_vpc.aws_eip.nat:
id = eipalloc-85c69ab0
association_id = eipassoc-d37d87e5
domain = vpc
instance =
network_interface = eni-bf367032
private_ip = 10.0.0.229
public_ip = 34.237.252.19
vpc = true
module.mgmt_vpc.aws_internet_gateway.main:
id = igw-0348f57a
tags.% = 1
tags.Name = mgmt
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_nat_gateway.nat:
id = nat-05f842507e06b84de
allocation_id = eipalloc-85c69ab0
network_interface_id = eni-704402fd
private_ip = 10.0.3.224
public_ip = 34.237.252.19
subnet_id = subnet-366f9f19
tags.% = 0
module.mgmt_vpc.aws_route.internet:
id = r-rtb-2078365a1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id = igw-0348f57a
instance_id =
instance_owner_id =
nat_gateway_id =
network_interface_id =
origin = CreateRoute
route_table_id = rtb-2078365a
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route.nat.0:
id = r-rtb-64632d1e1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id =
instance_id =
instance_owner_id =
nat_gateway_id = nat-05f842507e06b84de
network_interface_id =
origin = CreateRoute
route_table_id = rtb-64632d1e
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route.nat.1:
id = r-rtb-07632d7d1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id =
instance_id =
instance_owner_id =
nat_gateway_id = nat-05f842507e06b84de
network_interface_id =
origin = CreateRoute
route_table_id = rtb-07632d7d
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route.nat.2:
id = r-rtb-a47c32de1080289494
destination_cidr_block = 0.0.0.0/0
destination_prefix_list_id =
egress_only_gateway_id =
gateway_id =
instance_id =
instance_owner_id =
nat_gateway_id = nat-05f842507e06b84de
network_interface_id =
origin = CreateRoute
route_table_id = rtb-a47c32de
state = active
vpc_peering_connection_id =
module.mgmt_vpc.aws_route_table.private.0:
id = rtb-64632d1e
propagating_vgws.# = 0
route.# = 1
route.2946293433.cidr_block = 0.0.0.0/0
route.2946293433.egress_only_gateway_id =
route.2946293433.gateway_id =
route.2946293433.instance_id =
route.2946293433.ipv6_cidr_block =
route.2946293433.nat_gateway_id = nat-0ec0ce0ca12b73f43
route.2946293433.network_interface_id =
route.2946293433.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-private-0
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table.private.1:
id = rtb-07632d7d
propagating_vgws.# = 0
route.# = 1
route.2946293433.cidr_block = 0.0.0.0/0
route.2946293433.egress_only_gateway_id =
route.2946293433.gateway_id =
route.2946293433.instance_id =
route.2946293433.ipv6_cidr_block =
route.2946293433.nat_gateway_id = nat-0ec0ce0ca12b73f43
route.2946293433.network_interface_id =
route.2946293433.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-private-1
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table.private.2:
id = rtb-a47c32de
propagating_vgws.# = 0
route.# = 1
route.2946293433.cidr_block = 0.0.0.0/0
route.2946293433.egress_only_gateway_id =
route.2946293433.gateway_id =
route.2946293433.instance_id =
route.2946293433.ipv6_cidr_block =
route.2946293433.nat_gateway_id = nat-0ec0ce0ca12b73f43
route.2946293433.network_interface_id =
route.2946293433.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-private-2
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table.public:
id = rtb-2078365a
propagating_vgws.# = 0
route.# = 1
route.342141474.cidr_block = 0.0.0.0/0
route.342141474.egress_only_gateway_id =
route.342141474.gateway_id = igw-0348f57a
route.342141474.instance_id =
route.342141474.ipv6_cidr_block =
route.342141474.nat_gateway_id =
route.342141474.network_interface_id =
route.342141474.vpc_peering_connection_id =
tags.% = 1
tags.Name = mgmt-public
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_route_table_association.private.0:
id = rtbassoc-ffd56182
route_table_id = rtb-64632d1e
subnet_id = subnet-77649558
module.mgmt_vpc.aws_route_table_association.private.1:
id = rtbassoc-cfd165b2
route_table_id = rtb-07632d7d
subnet_id = subnet-a8fd4fe3
module.mgmt_vpc.aws_route_table_association.private.2:
id = rtbassoc-96eb5feb
route_table_id = rtb-a47c32de
subnet_id = subnet-77678d2a
module.mgmt_vpc.aws_route_table_association.public.0:
id = rtbassoc-ffb80e82
route_table_id = rtb-2078365a
subnet_id = subnet-366f9f19
module.mgmt_vpc.aws_route_table_association.public.1:
id = rtbassoc-94a711e9
route_table_id = rtb-2078365a
subnet_id = subnet-d9e65492
module.mgmt_vpc.aws_route_table_association.public.2:
id = rtbassoc-8fa016f2
route_table_id = rtb-2078365a
subnet_id = subnet-c86b8195
module.mgmt_vpc.aws_subnet.private.0:
id = subnet-77649558
assign_ipv6_address_on_creation = false
availability_zone = us-east-1a
cidr_block = 10.0.100.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-private-0
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.private.1:
id = subnet-a8fd4fe3
assign_ipv6_address_on_creation = false
availability_zone = us-east-1b
cidr_block = 10.0.112.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-private-1
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.private.2:
id = subnet-77678d2a
assign_ipv6_address_on_creation = false
availability_zone = us-east-1c
cidr_block = 10.0.120.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-private-2
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.public.0:
id = subnet-366f9f19
assign_ipv6_address_on_creation = false
availability_zone = us-east-1a
cidr_block = 10.0.0.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-public-0
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.public.1:
id = subnet-d9e65492
assign_ipv6_address_on_creation = false
availability_zone = us-east-1b
cidr_block = 10.0.12.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-public-1
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_subnet.public.2:
id = subnet-c86b8195
assign_ipv6_address_on_creation = false
availability_zone = us-east-1c
cidr_block = 10.0.20.0/22
map_public_ip_on_launch = false
tags.% = 1
tags.Name = mgmt-public-2
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_vpc.main:
id = vpc-b03e96c8
assign_generated_ipv6_cidr_block = false
cidr_block = 10.0.0.0/16
default_network_acl_id = acl-cdbc93b5
default_route_table_id = rtb-c17836bb
default_security_group_id = sg-3a6f4748
dhcp_options_id = dopt-5f48ea26
enable_classiclink = false
enable_classiclink_dns_support = false
enable_dns_hostnames = true
enable_dns_support = true
instance_tenancy = default
main_route_table_id = rtb-c17836bb
tags.% = 1
tags.Name = mgmt
module.mgmt_vpc.aws_vpc_endpoint.s3-private:
id = vpce-df3686b6
cidr_blocks.# = 2
cidr_blocks.0 = 54.231.0.0/17
cidr_blocks.1 = 52.216.0.0/15
policy = {"Statement":[{"Action":"","Effect":"Allow","Principal":"
","Resource":""}],"Version":"2008-10-17"}
prefix_list_id = pl-63a5400a
route_table_ids.# = 3
route_table_ids.1216147752 = rtb-07632d7d
route_table_ids.2661709090 = rtb-64632d1e
route_table_ids.625676261 = rtb-a47c32de
service_name = com.amazonaws.us-east-1.s3
vpc_id = vpc-b03e96c8
module.mgmt_vpc.aws_vpc_endpoint.s3-public:
id = vpce-753e8e1c
cidr_blocks.# = 2
cidr_blocks.0 = 54.231.0.0/17
cidr_blocks.1 = 52.216.0.0/15
policy = {"Statement":[{"Action":"","Effect":"Allow","Principal":"*
","Resource":"*"}],"Version":"2008-10-17"}
prefix_list_id = pl-63a5400a
route_table_ids.# = 1
route_table_ids.3869909465 <(386)%20990-9465> = rtb-2078365a
service_name = com.amazonaws.us-east-1.s3
vpc_id = vpc-b03e96c8
module.mgmt_vpc.data.aws_availability_zones.available:
id = 2017-11-02 21:14:31.083538555 +0000 UTC
names.# = 6
names.0 = us-east-1a
names.1 = us-east-1b
names.2 = us-east-1c
names.3 = us-east-1d
names.4 = us-east-1e
names.5 = us-east-1f
module.mgmt_vpc.data.template_file.num_availability_zones:
id = 4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce
rendered = 3
template = 3
module.mgmt_vpc.null_resource.vpc_ready:
id = 3854081390465364666

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-366f9f19,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

On Thu, Nov 2, 2017 at 2:24 PM, Samuel Gendler [e-mail] wrote:

Here's a log of 2 (out of 3) consecutive runs WITHOUT the network acls -
just the mgmt-vpc. It is succeeding, but it is blowing away a network and
the NAT gateway every single time (and the NAT gateway isn't fast to
restart!).

$ terragrunt apply --terragrunt-source ../../../../../stem-infra//vpc
_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:21 Running command: terraform --version
[terragrunt] 2017/11/02 14:09:21 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vp
c_mgmt/terraform.tfvars
[terragrunt] 2017/11/02 14:09:21 Cleaning up existing *.tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/02 14:09:21 Downloading Terraform configurations
from file:///Users/sgendler/src/stem/stem-infra into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM using terraform
init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:21 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:09:22 Running command: terraform init
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
-from-module=file:///Users/sgendler/src/stem/stem-infra
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/st
em/stem-infra"...
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] 2017/11/02 14:09:22 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:09:22 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:09:22 Backend s3 has not changed.
[terragrunt] 2017/11/02 14:09:22 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/../../../account.tfvars -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/terraform.tfvars -lock-timeout=20m
aws_vpc.main: Refreshing state... (ID: vpc-b03e96c8)
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
aws_subnet.private[1]: Refreshing state... (ID: subnet-a8fd4fe3)
aws_subnet.private[0]: Refreshing state... (ID: subnet-77649558)
aws_subnet.private[2]: Refreshing state... (ID: subnet-77678d2a)
aws_route_table.private[2]: Refreshing state... (ID: rtb-a47c32de)
aws_route_table.private[0]: Refreshing state... (ID: rtb-64632d1e)
aws_internet_gateway.main: Refreshing state... (ID: igw-0348f57a)
aws_subnet.public[2]: Refreshing state... (ID: subnet-c86b8195)
aws_route_table.private[1]: Refreshing state... (ID: rtb-07632d7d)
aws_subnet.public[0]: Refreshing state... (ID: subnet-086d9d27)
aws_subnet.public[1]: Refreshing state... (ID: subnet-d9e65492)
aws_route_table.public: Refreshing state... (ID: rtb-2078365a)
aws_vpc_endpoint.s3-private: Refreshing state... (ID: vpce-df3686b6)
aws_eip.nat: Refreshing state... (ID: eipalloc-85c69ab0)
aws_route_table_association.private[1]: Refreshing state... (ID:
rtbassoc-cfd165b2)
aws_route_table_association.private[0]: Refreshing state... (ID:
rtbassoc-ffd56182)
aws_route_table_association.private[2]: Refreshing state... (ID:
rtbassoc-96eb5feb)
aws_route_table_association.public[2]: Refreshing state... (ID:
rtbassoc-62bb0d1f)
aws_route_table_association.public[1]: Refreshing state... (ID:
rtbassoc-2ab40257)
aws_route_table_association.public[0]: Refreshing state... (ID:
rtbassoc-8cb006f1)
aws_vpc_endpoint.s3-public: Refreshing state... (ID: vpce-753e8e1c)
aws_route.internet: Refreshing state... (ID: r-rtb-2078365a1080289494)
aws_nat_gateway.nat: Refreshing state... (ID: nat-025791183dda99bb6)
aws_route.nat[1]: Refreshing state... (ID: r-rtb-07632d7d1080289494)
aws_route.nat[2]: Refreshing state... (ID: r-rtb-a47c32de1080289494)
aws_route.nat[0]: Refreshing state... (ID: r-rtb-64632d1e1080289494)
null_resource.vpc_ready: Refreshing state... (ID: 3854081390465364666)
module.mgmt_vpc.aws_route_table_association.public[0]: Destroying...
(ID: rtbassoc-8cb006f1)
module.mgmt_vpc.aws_route_table_association.public[2]: Destroying...
(ID: rtbassoc-62bb0d1f)
module.mgmt_vpc.aws_nat_gateway.nat: Destroying... (ID:
nat-025791183dda99bb6)
module.mgmt_vpc.aws_route_table_association.public[1]: Destroying...
(ID: rtbassoc-2ab40257)
module.mgmt_vpc.aws_route_table_association.public[2]: Destruction
complete after 0s
module.mgmt_vpc.aws_route_table_association.public[0]: Destruction
complete after 0s
module.mgmt_vpc.aws_route_table_association.public[1]: Destruction
complete after 0s
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-025791183dda99bb6, 50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Destruction complete after 53s
module.mgmt_vpc.aws_subnet.public[0]: Destroying... (ID: subnet-086d9d27)
module.mgmt_vpc.aws_subnet.public[0]: Destruction complete after 1s
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-6169994e)
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-d9e65492"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-6169994e"
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-6169994e"
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 0s (ID: rtbassoc-33a6104e)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 0s (ID: rtbassoc-8ebc0af3)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 0s (ID: rtbassoc-a9ba0cd4)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 1m43s (ID:
nat-0ec0ce0ca12b73f43)
module.mgmt_vpc.aws_route.nat[1]: Modifying... (ID:
r-rtb-07632d7d1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[0]: Modifying... (ID:
r-rtb-64632d1e1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[2]: Modifying... (ID:
r-rtb-a47c32de1080289494)
nat_gateway_id: "nat-025791183dda99bb6" => "nat-0ec0ce0ca12b73f43"
module.mgmt_vpc.aws_route.nat[1]: Modifications complete after 0s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[2]: Modifications complete after 0s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.aws_route.nat[0]: Modifications complete after 1s (ID:
r-rtb-64632d1e1080289494)

Apply complete! Resources: 5 added, 3 changed, 5 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-6169994e,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666
Samuels-MacBook-Pro:vpc_mgmt sgendler$ terragrunt apply
--terragrunt-source ../../../../../stem-infra//vpc_mgmt/
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:23 Running command: terraform --version
[terragrunt] 2017/11/02 14:14:23 Reading Terragrunt config file at
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vp
c_mgmt/terraform.tfvars
[terragrunt] 2017/11/02 14:14:23 Cleaning up existing *.tf files in
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
[terragrunt] 2017/11/02 14:14:23 Downloading Terraform configurations
from file:///Users/sgendler/src/stem/stem-infra into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM using terraform
init
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:23 Backend s3 has not changed.
[terragrunt] [/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt]
2017/11/02 14:14:24 Running command: terraform init
-backend-config=bucket=stem-terraform-state-bucket
-backend-config=key=aws2/us-east-1/_global/vpc_mgmt/terraform.tfstate
-backend-config=region=us-west-2 -backend-config=encrypt=true
-backend-config=dynamodb_table=terraform-lock-table -lock-timeout=20m
-from-module=file:///Users/sgendler/src/stem/stem-infra
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM
Copying configuration from "file:///Users/sgendler/src/st
em/stem-infra"...
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] 2017/11/02 14:14:24 Copying files from
/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt into
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:14:24 Setting working directory to
/var/folders/xr/t6gsrby97350k0r85qr7blzh0000gn/T/terragrunt/
1-Fiw_rVrVmzIDHkzOu35z2CQn0/N7YR7JXFv_AHrQ_vUpC9GGTlLbM/vpc_mgmt
[terragrunt] 2017/11/02 14:14:24 Backend s3 has not changed.
[terragrunt] 2017/11/02 14:14:24 Running command: terraform apply
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/../../../account.tfvars -var-file=/Users/sgendler/src/
stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../../region.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/_global/vpc_mgmt/../env.tfvars
-var-file=/Users/sgendler/src/stem/stem-envs/aws2/us-east-1/
_global/vpc_mgmt/terraform.tfvars -lock-timeout=20m
aws_vpc.main: Refreshing state... (ID: vpc-b03e96c8)
data.aws_availability_zones.available: Refreshing state...
data.template_file.num_availability_zones: Refreshing state...
aws_internet_gateway.main: Refreshing state... (ID: igw-0348f57a)
aws_route_table.public: Refreshing state... (ID: rtb-2078365a)
aws_subnet.public[2]: Refreshing state... (ID: subnet-c86b8195)
aws_subnet.public[0]: Refreshing state... (ID: subnet-6169994e)
aws_subnet.public[1]: Refreshing state... (ID: subnet-d9e65492)
aws_route_table.private[1]: Refreshing state... (ID: rtb-07632d7d)
aws_route_table.private[0]: Refreshing state... (ID: rtb-64632d1e)
aws_route_table.private[2]: Refreshing state... (ID: rtb-a47c32de)
aws_subnet.private[2]: Refreshing state... (ID: subnet-77678d2a)
aws_subnet.private[0]: Refreshing state... (ID: subnet-77649558)
aws_subnet.private[1]: Refreshing state... (ID: subnet-a8fd4fe3)
aws_eip.nat: Refreshing state... (ID: eipalloc-85c69ab0)
aws_vpc_endpoint.s3-private: Refreshing state... (ID: vpce-df3686b6)
aws_route.internet: Refreshing state... (ID: r-rtb-2078365a1080289494)
aws_route_table_association.public[0]: Refreshing state... (ID:
rtbassoc-8ebc0af3)
aws_route_table_association.public[2]: Refreshing state... (ID:
rtbassoc-33a6104e)
aws_route_table_association.public[1]: Refreshing state... (ID:
rtbassoc-a9ba0cd4)
aws_vpc_endpoint.s3-public: Refreshing state... (ID: vpce-753e8e1c)
aws_nat_gateway.nat: Refreshing state... (ID: nat-0ec0ce0ca12b73f43)
aws_route_table_association.private[1]: Refreshing state... (ID:
rtbassoc-cfd165b2)
aws_route_table_association.private[2]: Refreshing state... (ID:
rtbassoc-96eb5feb)
aws_route_table_association.private[0]: Refreshing state... (ID:
rtbassoc-ffd56182)
aws_route.nat[2]: Refreshing state... (ID: r-rtb-a47c32de1080289494)
aws_route.nat[1]: Refreshing state... (ID: r-rtb-07632d7d1080289494)
aws_route.nat[0]: Refreshing state... (ID: r-rtb-64632d1e1080289494)
null_resource.vpc_ready: Refreshing state... (ID: 3854081390465364666)
module.mgmt_vpc.aws_route_table_association.public[0]: Destroying...
(ID: rtbassoc-8ebc0af3)
module.mgmt_vpc.aws_nat_gateway.nat: Destroying... (ID:
nat-0ec0ce0ca12b73f43)
module.mgmt_vpc.aws_route_table_association.public[2]: Destroying...
(ID: rtbassoc-33a6104e)
module.mgmt_vpc.aws_route_table_association.public[1]: Destroying...
(ID: rtbassoc-a9ba0cd4)
module.mgmt_vpc.aws_route_table_association.public[2]: Destruction
complete after 1s
module.mgmt_vpc.aws_route_table_association.public[1]: Destruction
complete after 1s
module.mgmt_vpc.aws_route_table_association.public[0]: Destruction
complete after 1s
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still destroying... (ID:
nat-0ec0ce0ca12b73f43, 1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Destruction complete after 1m20s
module.mgmt_vpc.aws_subnet.public[0]: Destroying... (ID: subnet-6169994e)
module.mgmt_vpc.aws_subnet.public[0]: Destruction complete after 0s
module.mgmt_vpc.aws_subnet.public[0]: Creating...
assign_ipv6_address_on_creation: "" => "false"
availability_zone: "" => "us-east-1a"
cidr_block: "" => "10.0.1.0/22"
ipv6_cidr_block: "" => ""
ipv6_cidr_block_association_id: "" => ""
map_public_ip_on_launch: "" => "false"
tags.%: "" => "1"
tags.Name: "" => "mgmt-public-0"
vpc_id: "" => "vpc-b03e96c8"
module.mgmt_vpc.aws_subnet.public[0]: Creation complete after 3s (ID:
subnet-366f9f19)
module.mgmt_vpc.aws_route_table_association.public[0]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-366f9f19"
module.mgmt_vpc.aws_route_table_association.public[1]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-d9e65492"
module.mgmt_vpc.aws_route_table_association.public[2]: Creating...
route_table_id: "" => "rtb-2078365a"
subnet_id: "" => "subnet-c86b8195"
module.mgmt_vpc.aws_nat_gateway.nat: Creating...
allocation_id: "" => "eipalloc-85c69ab0"
network_interface_id: "" => ""
private_ip: "" => ""
public_ip: "" => ""
subnet_id: "" => "subnet-366f9f19"
module.mgmt_vpc.aws_route_table_association.public[2]: Creation complete
after 1s (ID: rtbassoc-8fa016f2)
module.mgmt_vpc.aws_route_table_association.public[0]: Creation complete
after 1s (ID: rtbassoc-ffb80e82)
module.mgmt_vpc.aws_route_table_association.public[1]: Creation complete
after 1s (ID: rtbassoc-94a711e9)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m10s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m20s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m30s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m40s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (1m50s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Still creating... (2m0s elapsed)
module.mgmt_vpc.aws_nat_gateway.nat: Creation complete after 2m4s (ID:
nat-05f842507e06b84de)
module.mgmt_vpc.aws_route.nat[0]: Modifying... (ID:
r-rtb-64632d1e1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[2]: Modifying... (ID:
r-rtb-a47c32de1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[1]: Modifying... (ID:
r-rtb-07632d7d1080289494)
nat_gateway_id: "nat-0ec0ce0ca12b73f43" => "nat-05f842507e06b84de"
module.mgmt_vpc.aws_route.nat[2]: Modifications complete after 1s (ID:
r-rtb-a47c32de1080289494)
module.mgmt_vpc.aws_route.nat[1]: Modifications complete after 1s (ID:
r-rtb-07632d7d1080289494)
module.mgmt_vpc.aws_route.nat[0]: Modifications complete after 1s (ID:
r-rtb-64632d1e1080289494)

Apply complete! Resources: 5 added, 3 changed, 5 destroyed.
Releasing state lock. This may take a few moments...

Outputs:

availability_zones = [
us-east-1a,
us-east-1b,
us-east-1c
]
nat_gateway_public_ips = [
34.237.252.19
]
num_availability_zones = 3
private_subnet_cidr_blocks = [
10.0.100.0/22,
10.0.112.0/22,
10.0.120.0/22
]
private_subnet_ids = [
subnet-77649558,
subnet-a8fd4fe3,
subnet-77678d2a
]
private_subnet_route_table_ids = [
rtb-64632d1e,
rtb-07632d7d,
rtb-a47c32de
]
public_subnet_cidr_blocks = [
10.0.0.0/22,
10.0.12.0/22,
10.0.20.0/22
]
public_subnet_ids = [
subnet-366f9f19,
subnet-d9e65492,
subnet-c86b8195
]
public_subnet_route_table_id = rtb-2078365a
vpc_cidr_block = 10.0.0.0/16
vpc_id = vpc-b03e96c8
vpc_name = mgmt
vpc_ready = 3854081390465364666

And here is the terragrunt plan output:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ module.mgmt_vpc.aws_nat_gateway.nat (new resource required)
id: "nat-05f842507e06b84de" =>
(forces new resource)
allocation_id: "eipalloc-85c69ab0" =>
"eipalloc-85c69ab0"
network_interface_id: "eni-704402fd" =>
private_ip: "10.0.3.224" =>
public_ip: "34.237.252.19" =>
subnet_id: "subnet-366f9f19" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

~ module.mgmt_vpc.aws_route.nat[0]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

~ module.mgmt_vpc.aws_route.nat[1]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

~ module.mgmt_vpc.aws_route.nat[2]
nat_gateway_id: "nat-05f842507e06b84de" =>
"${element(aws_nat_gateway.nat.*.id, count.index)}"

-/+ module.mgmt_vpc.aws_route_table_association.public[0] (new resource
required)
id: "rtbassoc-ffb80e82" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-366f9f19" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_route_table_association.public[1] (new resource
required)
id: "rtbassoc-94a711e9" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-d9e65492" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_route_table_association.public[2] (new resource
required)
id: "rtbassoc-8fa016f2" =>
(forces new resource)
route_table_id: "rtb-2078365a" => "rtb-2078365a"
subnet_id: "subnet-c86b8195" =>
"${element(aws_subnet.public.*.id, count.index)}" (forces new resource)

-/+ module.mgmt_vpc.aws_subnet.public[0] (new resource required)
id: "subnet-366f9f19" =>
(forces new resource)
assign_ipv6_address_on_creation: "false" => "false"
availability_zone: "us-east-1a" => "us-east-1a"
cidr_block: "10.0.0.0/22" => "10.0.1.0/22"
(forces new resource)
ipv6_cidr_block: "" =>
ipv6_cidr_block_association_id: "" =>
map_public_ip_on_launch: "false" => "false"
tags.%: "1" => "1"
tags.Name: "mgmt-public-0" => "mgmt-public-0"
vpc_id: "vpc-b03e96c8" => "vpc-b03e96c8"

Plan: 5 to add, 3 to change, 5 to destroy.

---

Note: You didn't specify an "-out" parameter to save this plan, so
Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Releasing state lock. This may take a few moments...

On Thu, Nov 2, 2017 at 2:14 PM, Samuel Gendler [e-mail] wrote:

For what it is worth, I included a perfect cut-and-paste copy of the
example code for the module for adding network ACLs to a mgmt-vpc and when
I ran it once, it creates the resources correctly on the first attempt.
When I applied it again, 2 minutes later, with absolutely no changes to
anything (I was debugging the provider cache thing), it still decided it
needed to kill a bunch of resources and re-create them, and then it exited
with an error about a network association with a particular id not
existing. I was surprised to see it update anything in the first place and
even more surprised to get errors on the second run that I didn't see the
first time. It seems kind of problematic if I cannot update some of the
most foundational pieces of infrastructure in your library... The only
thing I added was the following block to main.tf and copied the 2
outputs from the 2nd module.

module "mgmt_vpc" {
source = "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgm
t?ref=v0.3.1"

vpc_name = "${var.vpc_name}"
aws_region = "${var.aws_region}"
cidr_block = "${var.cidr_block}"
num_availability_zones = "${var.num_availability_zones}"
public_subnet_cidr_blocks = "${var.public_subnet_cidr_blocks}"
private_subnet_cidr_blocks = "${var.private_subnet_cidr_blocks}"
num_nat_gateways = "${var.num_nat_gateways}"
}

module "mgmt_vpc_network_acls" {

• source =
  "[email protected]:gruntwork-io/module-vpc.git//modules/vpc-mgmt-network-acls?ref=v0.3.1"*

• vpc_id = "${module.mgmt_vpc.vpc_id}"*
• vpc_name = "${module.mgmt_vpc.vpc_name}"*
• vpc_ready = "${module.mgmt_vpc.vpc_ready}"*

• num_subnets = "${module.mgmt_vpc.num_availability_zones}"*

• public_subnet_ids = "${module.mgmt_vpc.public_subnet_ids}"*

• private_subnet_ids = "${module.mgmt_vpc.private_subnet_ids}"*

• public_subnet_cidr_blocks =
  "${module.mgmt_vpc.public_subnet_cidr_blocks}"*

• private_subnet_cidr_blocks =
  "${module.mgmt_vpc.private_subnet_cidr_blocks}"*
  }

The 3rd time I applied it, it corrected the error from the 2nd time. The
4th time I ran it, it once again destroyed all of the public subnets and
recreated them, destroyed the NAT gateway and recreated it (which taks
minutes, not seconds) and then it once again died with the exact same error

• failed to find association for subnet: subnet-xxxxx

Error: Error applying plan:

1 error(s) occurred:

• module.mgmt_vpc_network_acls.aws_network_acl.public_subnets: 1
  error(s) occurred:

• aws_network_acl.public_subnets: Failed to find acl association: acl
  acl-6d381115 with subnet subnet-a6699989: could not find association for
  subnet: subnet-a6699989

The next time, it once again corrected the problem. So it is very
consistently working correctly every other time, implying some kind of bug
related to state and recognizing what is running versus what is expected to
be running.

So then I removed the 2nd module and the new outputs and tried running
it repeatedly again and got the same result - so the bug seems to be in
vpc-mgmt - it is failing to recognize that the incoming state matches the
expected state so it is making changes on every run even when nothing has
changed. At least without the network acls, it doesn't fail on every other
run, but the acls aren't the cause of the state change on every run. You
already have the code in the repos I sent last night plus the bold block
above. Nothing else has changed.

On Thu, Nov 2, 2017 at 1:49 PM, Samuel Gendler [e-mail] wrote:

And for what it is worth, I did enable the provider cache. It doesn't
seem to have helped at all. I have the cache directory and it has the
binaries in it, but it still downloads all the provider plugins on every
run. I'm assuming this is somehow the --terraform-source-update flag's
doing, but I just get constant errors if I ditch that.

On Thu, Nov 2, 2017 at 1:35 PM, Samuel Gendler [e-mail] wrote:

Yeah, but they actually lack all of the important parts that I was
looking for examples of - they don't demonstrate how to access a module
from within a template since they only use resources directly within the
*.tf files, and they don't show the cascading variable overrides and
instead of including empty directories for _global and region and account
layers in the hierarchy in order to demonstrate the concepts, those dirs
are entirely missing. That stuff took me 2 full days to get working due to
a combination of user error, bugs, and lack of documentation. I found
those repos within my first 20 minutes of exploration and was using them as
my model, but I still couldn't get modules to work from within the modules
repo (which should maybe be called the templates repo in order to avoid a
lot of unnecessary confusion over the difference between templates and
modules). I scoured the internet and your book for examples that combined
terragrunt with the use of modules in a template and they just don't seem
to exist, which is odd, since your reference architecture consists of
almost nothing but that exact pattern, I suspect. What I was looking for
was production-ready example repos that just have a minimum of templates
and configurations but are otherwise production-ready, whereas those really
are just quick examples of very simplistic code organization.

I was basically on the right track from the get go, but kept undoing
progress when bugs/user error would cause my experiments to fail even when
I was super close to the right thing. Honestly, I'm still running into
problems with it. When I just now ran it for the first time today, it blew
up with complaints about not having state locally and asking if I wanted to
refresh from s3. But I sure as heck don't know where my local state went.
And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code, but when I do use that flag, I have to wait
10-20 minutes for provider plugins to download from
releases.hashicorp.com. The problem is most definitely not network -
I can pull things from that host in a heartbeat via a web browser or curl -
but something is causing terraform to take forever when it loads those. As
a result, my turnaround rate is abysmal. Every minor change takes 30
minutes to validate against AWS.

On Thu, Nov 2, 2017 at 10:09 AM, Yevgeniy Brikman <
[email protected]> wrote:

Thanks, the explanation of what is going on with the path lunging was
very helpful. You should write that up somewhere public.

Glad it helped. I added it here: #341
https://github.com/gruntwork-io/terragrunt/pull/341.

That’s what needs to get out there - a starter implementation that is
just a mostly empty pair of repositories but with just enough to
demonstrate all of the common practices - cascading environment, region,
and account vars, etc. basically, exactly the pair of repos I sent last
night, plus maybe something about IAM best practices so that people are
doing the right thing from the start - it can be harder to add that stuff
in later.

Well, the two repos I linked you to earlier have some of that:

https://github.com/gruntwork-io/terragrunt-infrastructure-li
ve-example
https://github.com/gruntwork-io/terragrunt-infrastructure-mo
dules-example

PRs welcome to add anything that's missing or unclear!

And yes, the Reference Architecture
https://www.gruntwork.io/reference-architecture/ has all of that,
and then some!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341491877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqGTMTNYwrH3y0r8Qk2dJ3d1xJSIYks5syfcpgaJpZM4PxXd4
.

[brikis98]

Yeah, but they actually lack all of the important parts that I was looking for examples of - they don't demonstrate how to access a module from within a template since they only use resources directly within the *.tf files

Just added an example of using the Consul module from the Terraform Registry:

https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example/pull/2
https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/pull/3

It's merged now, so just browse the repos to see what it looks like.

and they don't show the cascading variable overrides

What variable overrides are you referring to?

and instead of including empty directories for _global and region and account layers in the hierarchy in order to demonstrate the concepts, those dirs are entirely missing

They show account (prod, non-prod) and region (us-east-1) layers. _global isn't anything exciting. It works exactly like anything else in the account and region layers.

What I was looking for was production-ready example repos that just have a minimum of templates and configurations but are otherwise production-ready, whereas those really are just quick examples of very simplistic code organization.

Production-ready code and "minimum" do not mix. Production-ready means you take into account security, scalability, maintainability, monitoring, configuration, reuse, versioning, and dozens of other things, so the example would end up quite large. Apologies for sounding like a broken record, but if you want something actually production ready, our Reference Architecture is what you're looking for :)

And I seem to be required to use --terragrunt-source-update or else it never sees my updated code

Are you using Git URLs or local file paths?

And for what it is worth, I did enable the provider cache. It doesn't seem to have helped at all. I have the cache directory and it has the binaries in it, but it still downloads all the provider plugins on every run. I'm assuming this is somehow the --terraform-source-update flag's doing, but I just get constant errors if I ditch that.

I'm not sure why you're so dead set on blaming Terragrunt for all your ills :-\

I have no clue why providers download slowly for you. Or why the cache wouldn't be working. Terragrunt has no influence on either one.

For what it is worth, I included a perfect cut-and-paste copy of the example code for the module for adding network ACLs to a mgmt-vpc and when I ran it once, it creates the resources correctly on the first attempt. When I applied it again, 2 minutes later, with absolutely no changes to anything (I was debugging the provider cache thing), it still decided it needed to kill a bunch of resources and re-create them, and then it exited with an error about a network association with a particular id not existing.

Please post all of your VPC issues in the VPC repo. I don't want to clutter this already very long thread with unrelated topics.

[ghost]

I didn't mean that it should implements production-ready infrastructure -
that's what your reference architecture is for. I meant that it
demonstrates a working installation of all of the terraform and terragrunt
and revision control systems that would need to be in place and correctly
configured to talk to each other to start the process of piecing together
infrastructure - a production development environment, if you will.

And I'm not necessarily blaming terragrunt for my ills just because I've
mentioned them here. I'm just going through what I'm sure are typical
teething problems with a new technology and trying to suggest ways that
Gruntworks, as a promoter of terraform and vendor of terraform-based
products, could do to ease the process of exploration. When push comes to
shove, I'm adopting both terraform and terragrunt simultaneously, with
terraform being, for all intents and purposes, a dependency of terragrunt,
so it doesn't seem unnatural to look to Gruntworks and terragrunt for
assistance in resolving the issues I'm encountering while I get familiar
with terragrunt. Yes, I could buy a fully functional architecture from you
and eliminate that process up front, but then the first time I need to make
changes to our purchased architecture, I'll be fighting through the same
teething problems but in a vastly more complicated architecture, not to
mention one that would be supporting production applications - finding my
way through the process of debugging the cascade of infrastructure updates
resulting from a simple typo in a CIDR block was hard enough with just a
single module with no dependencies instantiated. I can only imagine how
daunting it would be if I made a similar mistake in a fully specified
architecture. What I'm trying to do is get myself familiar and facile
enough with the tools that I can then confidently administrate and modify
what I'll likely purchase from you.

On Thu, Nov 2, 2017 at 5:19 PM, Yevgeniy Brikman [e-mail]
wrote:

Yeah, but they actually lack all of the important parts that I was looking
for examples of - they don't demonstrate how to access a module from within
a template since they only use resources directly within the *.tf files

Just added an example of using the Consul module
https://registry.terraform.io/modules/hashicorp/consul/aws/0.0.5 from
the Terraform Registry:

gruntwork-io/terragrunt-infrastructure-modules-example#2
https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example/pull/2
gruntwork-io/terragrunt-infrastructure-live-example#3
https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/pull/3

It's merged now, so just browse the repos to see what it looks like.

and they don't show the cascading variable overrides

What variable overrides are you referring to?

and instead of including empty directories for _global and region and
account layers in the hierarchy in order to demonstrate the concepts, those
dirs are entirely missing

They show account (prod, non-prod) and region (us-east-1) layers. _global
isn't anything exciting. It works exactly like anything else in the account
and region layers.

What I was looking for was production-ready example repos that just have a
minimum of templates and configurations but are otherwise production-ready,
whereas those really are just quick examples of very simplistic code
organization.

Production-ready code and "minimum" do not mix. Production-ready means you
take into account security, scalability, maintainability, monitoring,
configuration, reuse, versioning, and dozens of other things, so the
example would end up quite large. Apologies for sounding like a broken
record, but if you want something actually production ready, our Reference
Architecture is what you're looking for :)

And I seem to be required to use --terragrunt-source-update or else it
never sees my updated code

Are you using Git URLs or local file paths?

And for what it is worth, I did enable the provider cache. It doesn't seem
to have helped at all. I have the cache directory and it has the binaries
in it, but it still downloads all the provider plugins on every run. I'm
assuming this is somehow the --terraform-source-update flag's doing, but I
just get constant errors if I ditch that.

I'm not sure why you're so dead set on blaming Terragrunt for all your
ills :-\

I have no clue why providers download slowly for you. Or why the cache
wouldn't be working. Terragrunt has no influence on either one.

For what it is worth, I included a perfect cut-and-paste copy of the
example code for the module for adding network ACLs to a mgmt-vpc and when
I ran it once, it creates the resources correctly on the first attempt.
When I applied it again, 2 minutes later, with absolutely no changes to
anything (I was debugging the provider cache thing), it still decided it
needed to kill a bunch of resources and re-create them, and then it exited
with an error about a network association with a particular id not existing.

Please post all of your VPC issues in the VPC repo. I don't want to
clutter this already very long thread with unrelated topics.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-341595635,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdYOqIMXmSUVhCbq2Lx3R3CQMHhIkxHJks5sylwhgaJpZM4PxXd4
.

[antonbabenko]

Terraform 0.11 is out, and I think it is time for Terragrunt to have support for Terraform Registry URLs and versioning natively:

terragrunt = {
  terraform {
    source = "terraform-aws-modules/vpc/aws"
    version = "v1.2.0"
  }
}

As described in Upgrading to 0.11 Guide:

As a consequence, module source strings like "child" are no longer interpreted as relative paths. Instead, relative paths must be expressed explicitly by beginning the string with either ./ (for a module in a child directory) or ../ (for a module in the parent directory).

[brikis98]

+1. Anyone up for a PR?

[jeffbyrnes]

Seems like this has fallen by the wayside. Any chance of some love? I’d love to tackle, but have zero Go chops 😞

[brikis98]

We'd love to get to it, but there's a long list of feature requests for Terragrunt, and given that this one has a simple workaround (use a Git URL!), it's hard to prioritize it. PRs are welcome though :)

[seanorama]

@brikis98 while the Git URL works for fetching the modules, they will not work due to Terragrunt's requirement for the following which is not in the modules:

provider "aws" {
  region = "${var.aws_region}"
}

terraform {
  backend "s3" {}
}

Is there a workaround for that? Would be more DRY to not require that in every module.

[antonbabenko]

@seanorama I use hooks to copy that file like this:

terragrunt = {
  terraform {
    after_hook "copy_common_main_variables" {
      commands = ["init"]
      execute  = ["cp", "${get_parent_tfvars_dir()}/../common/main_variables.tf", "."]
    }
  }

[seanorama]

@antonbabenko Perfect.

How do you get around not having a double slash (//) when modules are in the root dir of a git repo? For example:
https://github.com/terraform-aws-modules/terraform-aws-vpc

[antonbabenko]

I usually don't need //, like this:

terragrunt = {
  terraform {
    source = "git::[email protected]:terraform-aws-modules/terraform-aws-vpc.git?ref=v1.24.0"
  }
}

[dennybaa]

@antonbabenko Would please tell how do you fix var.name issue (for example in case the vpc module)? It would be nice to have a fancy name calculated from other tfvars, though it's not possible terragrunt :(
Do you explicitly specify the name in terraform.tfvars?

[antonbabenko]

Yes, I always have name static in terraform.tfvars. An additional bonus is that I can use data-sources to lookup for that value if necessary because name is known and static.

[ozbillwang]

@antonbabenko

Any progress to support for Terraform Registry URLs and versioning natively:

https://github.com/gruntwork-io/terragrunt/issues/311#issuecomment-384991296

Currently I have to replace with below codes.

terragrunt = {
  terraform {
    source = "github.com/terraform-aws-modules/terraform-aws-autoscaling?ref=v2.9.0"
    #source = "terraform-aws-modules/autoscaling/aws"
    #version = "v2.9.0"
  }

  include = {
    path = "${find_in_parent_folders()}"
  }
}

[antonbabenko]

@ozbillwang I have not made any progress on this.

[chenrui333]

I am actually using something like this:

module "eks" {
  source                                                         = "terraform-aws-modules/eks/aws"
  version                                                        = "1.7.0"
...
}

It seems working good for me. So sounds like it does support terraform registry now?

[cschroer]

We tested with a private registry and latest terragrunt version:

Source:

 terraform {
    source  = "a-private-regisry.example.com/example-organisation/example-module/example-provider"
    version = "~> 1.0"
  }

Error:

Copying configuration from "file:///path/to/source/dir/a-private-regisry.example.com/example-organisation/example-module/example-provider"...
Error copying source module: error downloading 'file:///path/to/source/dir/a-private-regisry.example.com/example-organisation/example-module/example-provider': source path error: stat /path/to/source/dir/a-private-regisry.example.com/example-organisation/example-module/example-provider: no such file or directory

So at least for private registries it doesn't work (yet).

[antonbabenko]

@cschroer In your case source should start with https:// or http://. The default is file:// which you are experiencing.

[cschroer]

@antonbabenko not when using a module registry imho. See https://www.terraform.io/docs/modules/sources.html#terraform-registry

[brikis98]

This should now be possible using a generate block.

[antonbabenko]

@brikis98 I am not sure how generate block helps with this issue. Could you please describe the potential solution briefly?

[brikis98]

Whoops, going too quickly, this issue has nothing to do with generate block. Re-opening.