First attempt to replace template_file

[cahnk]

No description provided.

[lorengordon]

We are using template_file here intentionally because it actually templates strings, not files. There is no replacement in terraform, currently, for the string templating feature of this data source...

[cahnk]

Unfortunately template_file is deprecated in favor of the templatefile function. Our hand is being pushed. Kevin

…

Sent from my iPhone

On Jun 15, 2022, at 7:56 AM, Loren Gordon ***@***.***> wrote:  We are using template_file here intentionally because it actually templates strings, not files. There is no replacement in terraform, currently, for the string templating feature of this data source... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[cahnk]

Long and I discussed the following options for replacing the deprecated template_file data resource:

1. Use the templatefile function. Requires a file path. I tried using local_file resource, but the file is not being created. Even if it was, this is still not a good option since the temp file will cause plan to always detect changes.
2. Use template files in the terraform code that uses the modules and pass the file path into the module. This is the approach that Loren used in terraform-aws-tardigrade-iam-principals/modules/policy_document/main/.tf. This can work, but I worry about backwards compatibility. All users of the module will need to rewrite their code to use template files and pass the file paths to this module.
3. Use direct string interpolation ${var.variable_name}. This will work but i again worry about backwards compatibility. All users of the module will need to format their jsonencoded string with the correct string interpolation values and the correct number of $$. I tried this and for some reason the partition field is not valid after interpolation. All other fields are fine. This inconsistency doesn't make sense to me and is one of the frustrating things about writing terraform code.
4. Added - Have users pass in completed override_policy and policy arn strings to the module. The module users will be responsible for providing completed string to the module, so the module will not need to perform string interpolation. I tested this option and it works fine. I am not seeing any downsides of the option at this time. This is the approach i checked into the PR.

[lorengordon]

3. Use direct string interpolation ${var.variable_name}. This will work but i again worry about backwards compatibility. All users of the module will need to format their jsonencoded string with the correct string interpolation values and the correct number of $$. I tried this and for some reason the partition field is not valid after interpolation. All other fields are fine. This inconsistency doesn't make sense to me and is one of the frustrating things about writing terraform code.

I'm a tad surprised this worked at all. I'd be interested to see the code.

4. Added - Have users pass in completed override_policy and policy arn strings to the module. The module users will be responsible for providing completed string to the module, so the module will not need to perform string interpolation. I tested this option and it works fine. I am not seeing any downsides of the option at this time. This is the approach i checked into the PR.

The downside of this one is that we would not be able to call this module directly as the source in the terragrunt config, and let this module fill in the region, account id, and partition. Instead, we would just about always need to wrap the module call in a main.tf that uses the data sources to lookup the account id, region, and partition, in order to construct valid values. It works, it's just an annoying amount of boilerplate for every implementation.

Option 5 is to leave it as it is for now, unless something is actually not working. While deprecated, Hashicorp has stated this means the provider will remain available, but that it simply will not be not receiving updates.

The template provider is deprecated and the provider has been archived in accordance with HashiCorp's provider archiving process. While released versions of the provider will remain available, we recommend that you replace usages of this provider as follows.
https://registry.terraform.io/providers/hashicorp/template/latest/docs#deprecation

There has been a lot of discussion on how to support template strings as input variables, which we may eventually be able to use here:

• Render templates in a different module to where they are defined hashicorp/terraform#26838
• Introduce a template() function that works on string content hashicorp/terraform#30616
• lang/funcs: add template function hashicorp/terraform#24978
• Add templatestring function hashicorp/terraform#28686
• String templates as values hashicorp/terraform#28700

[cahnk]

I'll schedule a meeting for when you return Loren so you, Long, and I can discuss the way ahead on this one.

[lorengordon]

Closing for now. Will readdress later.