#pr-reviews (2022-02)

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin. To activate Renovate, merge this Pull Request. To disable Renovate,…

A Terraform module that creates IAM role with provided JSON IAM polices documents.

Describe the Feature

I am requesting the ability to pass a new input variable that defines a aws_iam_policy_document internal to the module, so that it gets constructed within the module rather than needing to pass in a JSON object to define the role policy.

This would enable all the modules inputs to be HCL rather than requiring a JSON input.

Expected Behavior

A variable iam_policy_object or something that is a custom object which lines up with the structure of aws_iam_policy_document, and that variable is the input to a data source inside of the module that creates the iam policy document.

Use Case

I prefer to define all infrastructure in HCL and use Terragrunt, so if I want to pass in a JSON object I usually use the terraform function json_encode() and pass in the HCL which would define the IAM policy. This would save me having to wrap my HCL inputs in json_encode()

Describe Ideal Solution

see expected behavior

Alternatives Considered

Using json_encode() isn’t terribly inconvenient

what

• remove unused template provider

why

• template provider does not have darwin/arm64 binary, modules including it don’t work on m1 mac.

Describe the Bug

If you run this module with -target 'aws_route53_zone.default[0]' you will get a hosted zone that has NS and SOA records.
Applying the module without such targeting will also create resource "aws_route53_record" "soa" which doesn’t include any customization options, therefore it isn’t currently valuable for this record to be managed in terraform.

If you implement this module for a private hosted zone like #52 allows, then for some reason resource "aws_route53_record" "soa" will fail to create.
Therefore I propose that resource "aws_route53_record" "soa" is removed from this module.

Unfortunately this will cause deletion of that resource for people who have provisioned this module.

Seeking input from @cloudposse members on how to proceed.

Expected Behavior

Route53 hosted zones can be created, whether public or private, and will contain an SOA record after creation

Steps to Reproduce

Steps to reproduce the behavior:

1. provision module with targeting so that only a hosted zone is created
2. see SOA record created in AWS console
3. destroy module
4. provision module without targeting to create hosted zone and SOA record
5. see SOA record created in AWS console
6. destroy module
7. provision module with VPC as enabled in #52
8. SOA record will fail to create

I don’t think that the SOA resource should be removed. Simply, private zones should not have SOAs created, because they do indeed fail to create and are only valid for public zones.

In #52 I’ve pushed changes to make that happen, however I’m running to other issues relating to the count meta attribute on the SOA resource.