#pr-reviews (2022-10)

what

• The current input variable service_registries requires all params to be defined. • This is rejected by AWS API, so currently it is not useable! • This PR allows any combination of input params for service_registries

why

• Currently if you do not use all input params, terraform would reject the code with errors attributes "container_name" and "container_port" are required • And if you try to supply all params, AWS API validation fails with Error: failed creating ECS service (EXAMPLE): InvalidParameterException: Specify a value for either 'port' or the 'containerName' and 'containerPort' combination, but not both. Remove one and retry. • This PR copies the variable definition from the upstream module terraform-aws-ecs-alb-service-task (code). This allows multiple possible combinations of input params as it should

what

Adding table_class option

why

This option can be usefull for tables with infrequent access. It can reduce costs by up to 60%.

references

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dynamodb_table#table_class
https://aws.amazon.com/fr/dynamodb/standard-ia/

what

• Adds a random string to the codepipeline module’s attributes to provide a unique name for the codepipeline bucket

why

• Automated tests sometimes fail due to bucket naming collisions (presumably when a previous test run failed and was not properly cleaned up)

references

• None

what

Use latest versions of the s3-log-storage module and label null

why

Be up to date

references

https://github.com/cloudposse/terraform-aws-s3-log-storage/releases/tag/0.28.3
https://github.com/cloudposse/terraform-null-label/releases

Resolves #211

have a chance to configure the name of the policy

what

• With this change i want to have an ability to provide a custom name for the policy

why

• the resources i’m working with were not created in the same way this module assumes • to have a chance to configure the name of the policy

have a chance to configure the name of the policy

what

• With this change i want to have an ability to provide a custom name for the policy

why

• the resources i’m working with were not created in the same way this module assumes • to have a chance to configure the name of the policy

what

• This PR will introduce logic to ignore certain CIDR ranges from either the requestor or acceptor VPC(s), without affecting the existing functionality.

why

• We add the CIDR range 100.64.0.0/16 to each of our EKS cluster VPCs to increase the maximum amount of assignable IP addresses when using the AWS VPC CNI. • This causes issues when attempting to leverage this existing peering module, as the 100.64.0.0/16 routes will conflict in certain cases. • One specific case is where we want to peer and route a single database or elasticsearch VPC to multiple different EKS cluster VPCs that all contain the 100.64.0.0/16 additional CIDR association

references

• https://aws.amazon.com/premiumsupport/knowledge-center/eks-multiple-cidr-ranges/

what

• Describe high-level what changed as a result of these commits (i.e. in plain-english, what do these changes mean?) • Use bullet points to be concise and to the point.

why

• Provide the justifications for the changes (e.g. business case). • Describe why these changes were made (e.g. why do these commits fix the problem?) • Use bullet points to be concise and to the point.

references

• Link to any supporting github issues or helpful documentation to add some context (e.g. stackoverflow). • Use closes #123, if this PR closes a GitHub issue #123

what

• IPv6 related descritption typo fix

why

• In IPv6 related outputs vars descrption contains IPv4 instead of IPv6

what

• This PR will introduce logic to ignore certain CIDR ranges from either the requestor or acceptor VPC(s), without affecting the existing functionality.

why

• We add the CIDR range 100.64.0.0/16 to each of our EKS cluster VPCs to increase the maximum amount of assignable IP addresses when using the AWS VPC CNI. • This causes issues when attempting to leverage this existing peering module, as the 100.64.0.0/16 routes will conflict in certain cases. • One specific case is where we want to peer and route a single database or elasticsearch VPC to multiple different EKS cluster VPCs that all contain the 100.64.0.0/16 additional CIDR association

references

• https://aws.amazon.com/premiumsupport/knowledge-center/eks-multiple-cidr-ranges/

what

• Use cloudposse/template for arm support

why

• The new cloudposse/template provider has a darwin arm binary for M1 laptops

references

• https://github.com/cloudposse/terraform-provider-template • https://registry.terraform.io/providers/cloudposse/template/latest

what

• Allow IPv6 communication b/w VPCs over VPC peering

why

• Application hosted in VPC-1 wants to access resources hosted in VPC-2 in private subnet over IPv6.