Add validation to ensure ecs service is deployed successfully

[raags]

SUMMARY

This expands the existing delay and repeat parameters to also check if a service is deployed successfully. This is done by checking the running count is equal to the desired count for the active deployment.

When the delay is set to 0, it'll disable this check.

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

ecs_service

ADDITIONAL INFORMATION

Currently, the ecs_service module starts a ECS service deployment but doesn't validate the deployment success. This change will optionally validate if the deployment succeeded, giving early feedback on the service status.

[ansibullbot]

cc @Java1Guy @jillr @kaczynskid @s-hertel @tremble @wimnat @zacblazic
click here for bot help

[markuman]

@raags thanks for your pr.

basically waiting for desired_count becomes equal running_count might not be sufficient in case your ecs service has got a load balancer configuration.
in this case you must wait until desired_count becomes equal to healthy targets in the belonging target group.
In case you update just the taskdefinition and the desired_count has not changed, it becomes more complicated. Because you must only count the healthy targets with the new taskdefinition.

In case you doesn't have a load balancer configuration (you do some background processing jobs with ecs), it might be sufficient.

You can achive something similar by using the elb_target_group_info modules.

- name: wait until at least one target is registered and healthy
  elb_target_group_facts:
    names:
      - "{{ SERVICE }}"
    collect_targets_health: yes
  register: TG
  retries: 10
  delay: 15
  until: TG.target_groups[0].targets_health_description | count == DESIRED_COUNT and TG.target_groups[0].targets_health_description[0].target_health.state == "healthy"

But as you see, it gets complicated. But it is definitely a "very nice to have" feature.

Furthermore, consider to add a waiter to the waiters.py file in the amazon.aws collection rather than writing a loop inside your module.
You'll find an example in this blog post by @jillr https://www.ansible.com/blog/getting-started-with-aws-ansible-module-development

[tremble]

There's actually 2 waiters already:

• https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecs.html#ECS.Waiter.ServicesInactive
• https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecs.html#ECS.Waiter.ServicesStable

They test for the states you're interested in. We often add waiters to amazon.aws because the built in waiters bomb out if you hit the API rate limits

[tremble]

Looking a little deeper into this PR, it looks like it's been superseded by #1209 which uses the botocore waiters.

@raags Thanks for taking the time to submit this PR. It looks like this PR stalled out a couple of years ago, and looking at the module as it stands today I believe that this has been achieved through a different mechanism. The updated behaviour should be available with community.aws 4.1.0. There's no fixed release dates yet.

I'm going to close out this PR, hopefully any future PRs won't spend quite so long waiting on reviews (we're finally getting on top of our backlog)