Terragrunt: Proposal: bring back support for configuration in terraform.tfvars

Created on 24 Jul 2019  路  1Comment  路  Source: gruntwork-io/terragrunt

Support for terraform.tfvars was removed in terragrunt 0.19 only because of https://github.com/hashicorp/terraform/issues/19424

That required everyone to basically rename the file to terragrunt.hcl and make some other adjustments. It required creating the inputs{} block with the variables, which are then get converted to env vars and then to actual vars by terraform. As this transformation doesn't always work well, we have to sometimes have two files: terraform.tfvars and terragrunt.hcl, keeping the variables set in terraform.tfvars and terragrunt configuration set in terragrunt.hcl.

There have been some other features added with terragrunt.hcl, for example terraform functions, but they are not used always. At least I haven't found a way to use this functionality at all.

Instead, terragrunt can:

  1. Check for the existence of terraform.tfvars. Check for the terragrunt variable there. If it's there then generate a file called terragrunt.tf with this content: variable "terragrunt" {}.
    This way terraform will not complain, all variables will be read correctly and there will be just one configuration file.
  2. If the file is not there, check for terragrunt.hcl file and parse it as usual.
question

Most helpful comment

Moving away from terraform.tfvars was recommended by HashiCorp in https://github.com/gruntwork-io/terragrunt/issues/466. I tend to agree, as that's a format native to Terraform, and it's likely to have other backwards incompatible changes in the future.

Moreover, I'm not a fan of code generation. It always sounds simple, but tends to introduce complexity. Just off the top of my head:

  1. We have to scan for terraform.tfvars, parse it, find a terragrunt variable, then find a possible source = "xxx" param, then either check out xxx or look at the .tf files in the current working dir, scan all of those, parse all of those, and make sure none of them declare a terragrunt variable already.
  2. If they don't, we have to generate a file. But where do we write it? If we put it in the current working dir, it will dirty your code base. Putting it in .terragrunt-cache makes more sense, but only works for users with source = "xxx" params that require downloading code into that dir.
  3. What if a terragrunt.tf already exists?
  4. When do we clean up terragrunt.tf?

So, overall, I'm not sure this is a road we want to go down.

>All comments

Moving away from terraform.tfvars was recommended by HashiCorp in https://github.com/gruntwork-io/terragrunt/issues/466. I tend to agree, as that's a format native to Terraform, and it's likely to have other backwards incompatible changes in the future.

Moreover, I'm not a fan of code generation. It always sounds simple, but tends to introduce complexity. Just off the top of my head:

  1. We have to scan for terraform.tfvars, parse it, find a terragrunt variable, then find a possible source = "xxx" param, then either check out xxx or look at the .tf files in the current working dir, scan all of those, parse all of those, and make sure none of them declare a terragrunt variable already.
  2. If they don't, we have to generate a file. But where do we write it? If we put it in the current working dir, it will dirty your code base. Putting it in .terragrunt-cache makes more sense, but only works for users with source = "xxx" params that require downloading code into that dir.
  3. What if a terragrunt.tf already exists?
  4. When do we clean up terragrunt.tf?

So, overall, I'm not sure this is a road we want to go down.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dmlemos picture dmlemos  路  3Comments

zachwhaley picture zachwhaley  路  3Comments

shaharmor picture shaharmor  路  3Comments

Tensho picture Tensho  路  3Comments

dingobar picture dingobar  路  3Comments