#pr-reviews (2024-09)
Pull Request Reviews for Cloud Posse Projects
2024-09-03
Small PR to fix a typo in terraform-aws-ecs-cloudwatch-sns-alarms/
.
Hight
-> High
what
Fix typo in alarm description
approved and merged, thanks @Lennart Goedhart
Hight
-> High
what
Fix typo in alarm description
2024-09-05
PR to enable the dualstack support in the RDS
https://github.com/cloudposse/terraform-aws-rds-cluster/pull/231
what
why
references
@Ben Smith (Cloud Posse) PR is passed. can you please check now
Merged
2024-09-06
PR to add the throughput
variable for block device tuning on ecs clusters https://github.com/cloudposse/terraform-aws-ecs-cluster/pull/53
what
This change adds the through put option to the ebs block_device_mappints object in the capacity_providers_fargate_ec2 variable
why
Support to tune the throughput of the ebs volumes was added to the autoscaling group module in version 0.37.1. As it is not defined in the option block here its not passed through during an execution.
references
Release notes for 0.37.1 of cloudposse/terraform-aws-ec2-autoscale-group
Closes #52
@Ben Smith (Cloud Posse)
what
This change adds the through put option to the ebs block_device_mappints object in the capacity_providers_fargate_ec2 variable
why
Support to tune the throughput of the ebs volumes was added to the autoscaling group module in version 0.37.1. As it is not defined in the option block here its not passed through during an execution.
references
Release notes for 0.37.1 of cloudposse/terraform-aws-ec2-autoscale-group
Closes #52
@Igor Rodionov
I guess these got pulled in during the merge from main, I’ve updated them regardless as its a trivial update
@Ben Smith (Cloud Posse) @Igor Rodionov bumping this up
Is there a step I have missed here? Looks like the terratest has not completed but I am not sure why
Merged. These changes were released in v0.7.0.
2024-09-08
what
RDS cluster can be run in two network modes - IPV4 or DUAL.
Underlying module already supports this parameter
why
It can be mandatory to enable it to be able to connect from ipv6 only runtimes
references
Closes #175
2024-09-09
2024-09-10
2024-09-11
what
This avoids a situation where the reader endpoint tries to use coalesce(null, null, null)
when in cluster mode and instead uses the configuration endpoint.
why
When using cluster mode there is no reader endpoint so the output tries to use coalesce(null, null, null)
which results in a plan error. As outlined in the AWS docs the config endpoint should be used instead when in cluster mode.
references
Closes #236
@Ben Smith (Cloud Posse) @Igor Rodionov
what
This avoids a situation where the reader endpoint tries to use coalesce(null, null, null)
when in cluster mode and instead uses the configuration endpoint.
why
When using cluster mode there is no reader endpoint so the output tries to use coalesce(null, null, null)
which results in a plan error. As outlined in the AWS docs the config endpoint should be used instead when in cluster mode.
references
Closes #236
Can someone run the terratest again on following PR
Error: reading Route 53 Hosted Zone (Z04545531TH4B1BZM9PY8): couldn’t find resource https://github.com/cloudposse/terraform-aws-elasticache-redis/actions/runs/10830359174/job/30049986131#step<i class="em em-12"1099 │ https://github.com/cloudposse/terraform-aws-elasticache-redis/actions/runs/10830359174/job/30049986131#step<i class="em em-12"1100 │ with module.redis.module.dns.aws_route53_record.default[0], https://github.com/cloudposse/terraform-aws-elasticache-redis/actions/runs/10830359174/job/30049986131#step<i class="em em-12"1101 │ on .terraform/modules/redis.dns/main.tf line 15, in resource “aws_route53_record” “default”: https://github.com/cloudposse/terraform-aws-elasticache-redis/actions/runs/10830359174/job/30049986131#step<i class="em em-12"1102 │ 15: resource “aws_route53_record” “default” { https://github.com/cloudposse/terraform-aws-elasticache-redis/actions/runs/10830359174/job/30049986131#step<i class="em em-12"1103 │ https://github.com/cloudposse/terraform-aws-elasticache-redis/actions/runs/10830359174/job/30049986131#step<i class="em em-12"1104 ╵}
@Ben Smith (Cloud Posse) @Igor Rodionov
@Igor Rodionov is this due to a missing zone in the new test account maybe?
Nitin, we are chasing this internally and will get back to you asap
@Nitinthat merged. The problem was because we had to update the PR base branch.
2024-09-12
2024-09-13
2024-09-14
what
Allow IPv6 communication b/w VPCs over VPC peering
why
Application hosted in VPC-1 wants to access resources hosted in private subnet of VPC-2 over IPv6.
references
@Nitin it seems to be failing Terratest
what
Allow IPv6 communication b/w VPCs over VPC peering
why
Application hosted in VPC-1 wants to access resources hosted in private subnet of VPC-2 over IPv6.
references
@Gabriela Campana (Cloud Posse) i checked. but this error not with the changes of my code.. can you help me with it.?
@Igor Rodionov is this a test failing due to opentofu / terraform concurrency?
Nitin, we are chasing this internally and will get back to you asap
@Igor Rodionov bumping this up
@Igor Rodionov @Andriy Knysh (Cloud Posse)
@Nitin I was working on triaging this bug last week. Still in progress. ETA this week. WIll keep you updated
@Nitin good news. I fixed the tests. So there is no technical block for your PR. Just one point in the PR looks hard for me. Could we simplify the code I mentioned in the PR comments? https://github.com/cloudposse/terraform-aws-vpc-peering-multi-account/pull/101#pullrequestreview-2328471273 ?
@Igor Rodionov can you test now
i have made the changes
@Igor Rodionov can you please rerun
@Nitin thanks. Your PR merged https://github.com/cloudposse/terraform-aws-vpc-peering-multi-account/releases/tag/v0.20.1
2024-09-16
2024-09-17
2024-09-18
@Erik Osterman (Cloud Posse) terratest is passed.
@Gabriela Campana (Cloud Posse) can you please assign someone for approval and merge
@Andriy Knysh (Cloud Posse)
@Igor Rodionov
Merged
These changes were released in v0.19.4.
@Gabriela Campana (Cloud Posse) https://github.com/cloudposse/terraform-aws-elasticache-memcached/issues/55
Have a question? Please checkout our Slack Community or visit our Slack Archive.
Describe the Feature
Allow setting network_type
argument in aws_elasticache_cluster
managed by module.
Expected Behavior
Add module variable to set https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/elasticache_cluster.html#network_type
Use Case
I need to create memcached cluster with network_type = "dual_stack"
in dualstack subnet.
Describe Ideal Solution
See ‘Expected Behaviour’
Alternatives Considered
Drop this module, manage aws_elasticache_cluster
on my own.
Additional Context
None.
@Igor Rodionov
what
Redis cluster can be run in 3 network modes - ipv4, ipv6 or dual_stack.
Underlying module already supports this parameter
why
It can be mandatory to enable it to be able to connect from dual_stack or ipv6 only runtimes
references
@Igor Rodionov @Ben Smith (Cloud Posse)
what
Redis cluster can be run in 3 network modes - ipv4, ipv6 or dual_stack.
Underlying module already supports this parameter
why
It can be mandatory to enable it to be able to connect from dual_stack or ipv6 only runtimes
references
2024-09-19
what
Fix the description and README documentation for the logging
variable. It looks like it was copypasta from the kms_key_id
variable description.
why
Because the description does not match the functionality.
This PR has been approved (thanks!) but not yet merged.
what
Fix the description and README documentation for the logging
variable. It looks like it was copypasta from the kms_key_id
variable description.
why
Because the description does not match the functionality.
@Igor Rodionov
because tests are failing
Tests weren’t even run before, so I think it was just that no-one with permissions had run /terratest
And since this is a doc change only, it seems unlikely to be related to a terratest
failure, but I can definitely take a look at it.
@Igor Rodionov aware
2024-09-20
what
• Replace context with default variable
why
• When using container within GitHub Actions, context value is incorrect. Default variable value remains correct. • As github.action_path is used during step execution (within runner), it can be replaced by default variable.
references
There are more reported issues showing this problem in various scenarios, for instance this one
@Igor Rodionov cc @Gabriela Campana (Cloud Posse)
what
• Replace context with default variable
why
• When using container within GitHub Actions, context value is incorrect. Default variable value remains correct. • As github.action_path is used during step execution (within runner), it can be replaced by default variable.
references
There are more reported issues showing this problem in various scenarios, for instance this one
@Igor Rodionov bumping this up
@Michal Tomaszek thanks for your contribution. We merged it and released at
@Igor Rodionov I noticed the comments are not on the PRs with the release version
@Erik Osterman (Cloud Posse) yea. For GHA I merge PRs into temporary branch and run test for temporary PR.. that’s why. Actually I think we need for GHA tests use the same pattern we use for terraform modules testing. But I had not time to update workflows yet
2024-09-21
what
Redis cluster can be run in 3 network modes - ipv4, ipv6 or dual_stack.
Underlying module already supports this parameter
why
It can be mandatory to enable it to be able to connect from dual_stack or ipv6 only runtimes
references
approved, thanks @Nitin
what
Redis cluster can be run in 3 network modes - ipv4, ipv6 or dual_stack.
Underlying module already supports this parameter
why
It can be mandatory to enable it to be able to connect from dual_stack or ipv6 only runtimes
references
These changes were released in v1.6.0.
2024-09-22
2024-09-23
2024-09-24
2024-09-25
I addressed mergify’s conflicts, however, I don’t have the ability to re-open this PR. ~Would someone please re-open it, or let me know if I should just submit a new PR?~ Thanks @Jeremy White (Cloud Posse) for re-opening the PR.
Looks like we just need /terratest
to kick off now
@Jeremy G (Cloud Posse) @Jeremy White (Cloud Posse)
Sorry got pulled away by more things. But the PR is approved and all green. @Tyler Rankin, can you merge?
Looks like there are still a couple workflows that need an approval to run
Awesome, looks like the final workflow checks ran and passed.
@Jeremy White (Cloud Posse) I don’t have write access so it doesn’t let me merge but it looks like it should be good to go!
@Jeremy White (Cloud Posse) bumping this up Also tagging @Ben Smith (Cloud Posse), who might be able to merge it
Not sure if/when mergify might close this again, so just wanted to send a friendly bump here
2024-09-26
2024-09-27
PR to support delete protection in dynamodb
https://github.com/cloudposse/terraform-aws-components/pull/1118
what
terraform-aws-dynamodb v0.36.0 supports delete protection on the table. This Pull request exposes that upstream variable
why
Delete safe dynamodb tables in the dynamo component
references
https://github.com/cloudposse/terraform-aws-dynamodb/blob/0.36.0/variables.tf#L184-L188
@RB just let me know I need to update docs, let me do that
what
terraform-aws-dynamodb v0.36.0 supports delete protection on the table. This Pull request exposes that upstream variable
why
Delete safe dynamodb tables in the dynamo component
references
https://github.com/cloudposse/terraform-aws-dynamodb/blob/0.36.0/variables.tf#L184-L188
Fixed the documents. Sorry about that
2024-09-30
what
• Support for serverless v2 to ensure that configurations (like HTTP endpoints for the Data API) are correctly enabled on instances using the serverless v2 implementation. • A new condition, is_serverless_v2, was introduced to identify serverless v2 instances based on the specific configuration parameters required for its activation.
why
• The original code was intended to enable_http_endpoint
based on whether the database instance was using serverless architecture. With the introduction of serverless v2 for certain database engines, there is a need to update the logic to accommodate these options.
references
Closes #193
@Igor Rodionov can you review this?
what
• Support for serverless v2 to ensure that configurations (like HTTP endpoints for the Data API) are correctly enabled on instances using the serverless v2 implementation. • A new condition, is_serverless_v2, was introduced to identify serverless v2 instances based on the specific configuration parameters required for its activation.
why
• The original code was intended to enable_http_endpoint
based on whether the database instance was using serverless architecture. With the introduction of serverless v2 for certain database engines, there is a need to update the logic to accommodate these options.
references
Closes #193
@Ben Smith (Cloud Posse)
@Lennart Goedhart, thanks for the contribution. Your PR merged and released https://github.com/cloudposse/terraform-aws-rds-cluster/releases/tag/v1.12.0