.yml files no loger supported ?

[ep4sh]

Accordingly commit I see you have deleted all .yml files, could you please explain is it best practice to use them for variables?

[yorinasub17]

.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.

[ep4sh]

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?

[yorinasub17]

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

[ep4sh]

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?

[yorinasub17]

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.

[ep4sh]

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"..

[yorinasub17]

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 includes, due to the complexity of implementing a cross configuration references of locals.