.yml files no loger supported ?
ep4sh opened this issue · comments
Accordingly commit I see you have deleted all .yml files, could you please explain is it best practice to use them for variables?
.yml
is still supported and can be used, but with the introduction of read_terragrunt_config
, you can also use .hcl
for that purpose. The benefit of using hcl
over yaml
is that yaml is a static data language, so you don't have any support for computations and processing over the data. With hcl
, you have access to all the functions terragrunt supports, and the ability to compose locals to construct more complex expressions. We feel that this is going to be a more extensible practice than using yaml, and thus we switched our examples over. That said, it really comes down to personal preference: both are valid formats for this purpose and you should use whichever feels better.
Thanks for this answer, could you please also tell, read_terragrunt_config
and import
are similar functions?
I try to create GLOBAL
vars in terragrunt.hcl
and retrieve them in module's terragrunt.hcl
How can I realize it?
The feature you are looking for is the import
block which just completed the design cycle, but is not implemented yet. See the RFC for more details: https://github.com/gruntwork-io/terragrunt/blob/master/_docs/rfc/imports.md
So at the moment, I cant do it simply with read_terragrunt_config
, I mean I can read child config, but nor the parent, right?
You can read the parent as well, but you can't have cycles. That is, you can't have the child read the parent to expose child vars to the parent, while simultaneously having the child read the parent to get the parent vars.
Can I define the parent list/map/list of maps value (on the root level) and then refine it (on env level)?
For e.g. in terrafrunt.hcl
:
locals {
vpc_list = {
vpc_a = "vpc_bla1",
vpc_b = "vpc_bla2",
}
}
In the env.hcl
:
locals {
vpc_name = "vpc_a"
vpc_id = local.vpc_list[vpc_name]
}
I tried to do that but getting error that "value cannot be evalueted"..
Unfortunately, that is not supported. locals
are local to the configuration that defined it (that's why they are called "local", as opposed to "global") and are not automatically merged across include
s, due to the complexity of implementing a cross configuration references of locals
.