-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating family to use ecs_service_name var #8
Conversation
…ervice-task into adding-autoscaling
…ervice-task into adding-autoscaling
…ervice-task into adding-autoscaling
…ervice-task into adding-autoscaling
@@ -51,7 +51,7 @@ module "exec_label" { | |||
|
|||
resource "aws_ecs_task_definition" "default" { | |||
count = local.create_task_definition ? 1 : 0 | |||
family = module.this.name | |||
family = var.ecs_service_name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ecs_service_name
isn't a required variable, and can be null
.
If you want this the same as the service name (probably a good idea), make sure you're setting it to the same things as the service name. In this case, that would be var.ecs_service_name != null ? var.ecs_service_name : module.this.id
Though looking at it again, I think that should actually be module.service_label.id
(both here and in the actual aws_ecs_service
resource definition further down. service_label
sets label_order to ["name", "attributes"]
, so two service task modules with the same "name" but different attributes (ie "web" vs "worker") should have things named uniquely.
what
The module.this.name worked for the web apps, but not for the workers. So by updating this, we'll be able to tie the ECS service name to the container definition instead of the module name. Because the web and worker technically use the same module.
why
So we don't mess up worker family names.
references
https://kininsurance.atlassian.net/browse/DK-389