Should Terragrunt 0.19 convert var files into env vars ?

[barryib]

Now in Terraform 0.12, every variable should be declared. So when you use a common variables (like global.tfvars) which are always loaded by Terragrunt, you get a warning in Terraform 0.12 and you'll get an error in Terraform 0.13.

How do we handle this ? Is Terragrunt should load those files as env vars prefixed with TF_VAR_ ? Should we add another attribute for env vars file ? Something like :

terraform {
  extra_arguments "custom_env_vars" {
    commands = "${get_terraform_commands_that_need_vars()}"

    required_env_files = [
      "${get_terragrunt_dir()}/${find_in_parent_folders("global.tfvars")}",
    ]
    optional_env_files = [
      "${get_terragrunt_dir()}/${find_in_parent_folders("optinal.tfvars", "ignore")}"
    ]
  }
}

[brikis98]

Yea, the change in Terraform 0.12 to be more strict about what can be passed via -var and -var-file is in some ways good, as you may catch more errors (e.g., typo in var name), but is a bit problematic, as it doesn't allow you to dump lots of common variables in .tfvars files.

Having Terragrunt convert .tfvars files to environment variables is an option, but feels a bit hacky, and it's not out of the question that the same restriction will be applied to TF_VAR_xxx env vars in the future. In fact, I'm wondering if I should've passed the contents of the inputs = { ... } block using -var arguments instead of env vars...

Another option is to add a new get_input helper that can read values from other files. E.g. the terragrunt.hcl of an app may contain:

# stage/frontend-app/terragrunt.hcl

inputs = {
  aws_region = get_input("../../common.hcl", "aws_region")
  remote_state_bucket = get_input("../../common.hcl", "remote_state_bucket")

  instance_type = "t2.micro"
  instance_count = 10
}

And common.hcl may define:

inputs = {
  aws_region = "us-east-1"
  remote_state_bucket = "my-staging-bucket"
}

This approach matches the Terraform philosophy of "explicit over implicit," but the downside is that it's verbose and repetitive.

On a side note, the get_input helper would pair nicely with a get_output helper that runs terragrunt output on another module:

inputs = {
  # Read an output from the VPC module
  vpc_id = get_output("../vpc", "vpc_id")
}

Again, this is explicit over implicit, giving you a clear, visible definition of dependencies between modules.

Other ideas are welcome!

[kelsmj]

If I am not mistaken, this has also made it difficult to have a variable in the global.tfvars file and then override it in a child terragrunt.hcl file. e.g. have a default instance_type variable of "t2.micro" then change that on a case by case basis to something else further on down the chain.

[ekini]

I've created the pull request to allow undeclared variables from -var-file. It will restore previous functionality without introducing complicated logic.

Personally, I don't see any reason why it was introduced apart from giving feedback to users who make typos: https://github.com/hashicorp/terraform/blob/master/backend/unparsed_value.go#L61

[ekini]

The PR was rejected despite the warnings were clearly not supported by the community: hashicorp/terraform#19424

So I'm not sure what to do with it.

[barryib]

closing in favor of #752

[ekini]

Well, I think this issue is about something different: warnings generated for undeclared variables set globally in common.hcl, for example.
#752 is not going to solve that, unfortunately.

[barryib]

@ekini I think this issue is about making decision to be implicit or to follow Terraform by defining explicitly variables.

For me, both #737 and #752 are defining how to handle inputs.

But if you want, I can reopen this issue and rename its title into something like : How Terragrunt should handle inputs ?