#refarch (2023-12)
Cloud Posse Reference Architecture
2023-12-12
Describe the Bug
https://github.com/cloudposse/terraform-aws-components/blob/main/modules/ecs-service/main.tf#L259
deployment_controller_type = lookup(local.task, "deployment_controller_type", null)
ends up passing in null
which does not default to ECS
for this conditional https://github.com/cloudposse/terraform-aws-ecs-alb-service-task/blob/main/main.tf#L642 so circuit_breaker_deployment_enabled
and circuit_breaker_rollback_enabled
never get enabled.
Expected Behavior
...
task:
circuit_breaker_deployment_enabled: true
circuit_breaker_rollback_enabled: true
…should trigger…
~ deployment_circuit_breaker {
~ enable = false -> true
~ rollback = false -> true
}
Changing the values should trigger an update, but it requires manually setting deployment_controller_type: ECS
.
Steps to Reproduce
Enable the circuit breaker for a task without explicitly setting the deployment controller.
Screenshots
No response
Environment
No response
Additional Context
No response
@Jeremy White (Cloud Posse) @Ben Smith (Cloud Posse) have either of you seen this bug in recent ECS engagements?
Describe the Bug
https://github.com/cloudposse/terraform-aws-components/blob/main/modules/ecs-service/main.tf#L259
deployment_controller_type = lookup(local.task, "deployment_controller_type", null)
ends up passing in null
which does not default to ECS
for this conditional https://github.com/cloudposse/terraform-aws-ecs-alb-service-task/blob/main/main.tf#L642 so circuit_breaker_deployment_enabled
and circuit_breaker_rollback_enabled
never get enabled.
Expected Behavior
...
task:
circuit_breaker_deployment_enabled: true
circuit_breaker_rollback_enabled: true
…should trigger…
~ deployment_circuit_breaker {
~ enable = false -> true
~ rollback = false -> true
}
Changing the values should trigger an update, but it requires manually setting deployment_controller_type: ECS
.
Steps to Reproduce
Enable the circuit breaker for a task without explicitly setting the deployment controller.
Screenshots
No response
Environment
No response
Additional Context
No response
Haven’t, but I’ve not seen folks using the circuit breaker in general until this bug report.
This looks like a relatively easy fix to the component by changing some inputs and or the conditionals. If you have time to write a PR to this I’d be happy to review and merge this, otherwise I can try to get to it, though my plate is pretty loaded ATM. How much of a blocker is this issue>
@johncblandii
It isn’t a blocker since we found a way to work around it
2023-12-13
2023-12-15
2023-12-21
Found a tiny bug in the spacelift-stack module in terraform-spacelift-cloud-infrastructure-automation Posting in this channel as it feels like the closest fit for this issue.
https://github.com/cloudposse/terraform-spacelift-cloud-infrastructure-automation/issues/159
“Downstream” bug in aws-terraform-components is now logged here https://github.com/cloudposse/terraform-aws-components/issues/939
@Dan Miller (Cloud Posse)
what
• Change the resource type used for var.context_attachments
and var. policy_ids
to a list of strings rather than a set of strings
why
• The terraform logic for Spacelift stack attachments (found in attachments.tf) uses a terraform for-loop in the two-symbol form to retrieve the index in each iteration of the loop. This leads to an error as the type of the variables used for these attachments is set(string), which does not support two-symbol loops.
references
• closes #159 • related to cloudposse/terraform-aws-components#939
what
• Change the resource type used for var.context_attachments
to a list of strings rather than a set of strings
why
• The terraform logic for Spacelift stack attachments (found in attachments.tf) uses a terraform for-loop in the two-symbol form to retrieve the index in each iteration of the loop. This leads to an error as the type of the variables used for these attachments is set(string), which does not support two-symbol loops.
references
• cloudposse/terraform-spacelift-cloud-infrastructure-automation#160 • resolves #939