ecs_service planning

[markuman]

Summary

ecs_service needs some care

the three most important ToDos

• [x] make ecs_cluster integration test work again: https://github.com/ansible-collections/community.aws/pull/1145
• [x] aws terminator policy and termination class to include it to CI/CD again: https://github.com/mattclay/aws-terminator/pull/210
• [x] implement waiters: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecs.html#waiters
  • https://github.com/ansible-collections/community.aws/pull/1209

---

easy, good first issues

• [ ] snake_dict parameter output of
  • ecs_service
  • ecs_service_info
• [x] service and name parameter/aliases in ecs_service and ecs_service_info
  • bring the modules closer to each other that they support the same parameter/aliases for the ecs service name
• [ ] limit placement_constraints to max 10 (verify what docs told)

---

features

• [x] https://github.com/ansible-collections/community.aws/issues/1137
  • https://github.com/ansible-collections/community.aws/pull/1181#issuecomment-1141366008
• [x] Support force_new_deployment without having to specify a task definition
• [x] circuit breaker settings missing in ecs_service module

---

bugs

• [x] ecs_service cannot handle distinctInstance Placement Constraint - https://github.com/ansible-collections/community.aws/pull/1170

[markuman]

bot_skip

[markuman]

everyone who is bored can join

[jatorcasso]

@markuman I can poke at a few of these after #1145 gets merged

[jatorcasso]

@markuman where are waiters needed here? are there specific test cases I can look at to validate the waiters do their job? I see for scaling down services

[markuman]

@markuman where are waiters needed here? are there specific test cases I can look at to validate the waiters do their job? I see for scaling down services

yes. one case is when the service is state: absent, it must wait until the service is inactive.
it would make this retry https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/ecs_cluster/tasks/main.yml#L983-L991 superfluous, because the cluster can only be removed when no service is available anymore.
wait: yes in this tasks inside the always block: https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/ecs_cluster/tasks/main.yml#L877-L916

another case is when the desired_count changes. https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/ecs_cluster/tasks/main.yml#L301-L319
or when the service is created. it must wait until the service is table: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecs.html#ECS.Waiter.ServicesStable
this would also solves this PR: https://github.com/ansible-collections/community.aws/pull/91

[markuman]

something else that might be need to be discussed is the format of the task_definition.

The input format is documented like this: https://github.com/ansible-collections/community.aws/blob/main/plugins/modules/ecs_service.py#L214

    task_definition: 'new_cluster-task:1'

But the output is returning just the arn of the task_definition:

• https://github.com/ansible-collections/community.aws/blob/main/plugins/modules/ecs_service.py#L308-L309
• https://github.com/ansible-collections/community.aws/blob/main/plugins/modules/ecs_service.py#L424-L425

    taskDefinition: arn:aws:ecs:eu-central-1:123456789:task-definition/new_cluster-task:1

Shall we support both as valid input formats?

[tremble]

Shall we support both as valid input formats?

Having dealt with all sorts of cross-account fun in the past few years, I'm a fan of supporting full ARNs in addition to just the names.

[jatorcasso]

@ingmarfjolla this could be a good first contribution for ya

[alinabuzachis]

@markuman Can you please check what's missing in here?

[markuman]

@markuman Can you please check what's missing in here?

@alinabuzachis done. only two items are left. but they are more cosmetic in nature.