community.aws
community.aws copied to clipboard
ecs_taskdefinition idempotency fails for containerDefinition secrets
SUMMARY
ecs_taskdefinition idempotency checks fail if secrets are supplied in a containerDefinition.
This appears to be because boto3 doesn't actually return the secrets in describe_task_definition, so the _right_has_values_of_left fails.
Can't really be fixed in Ansible until boto3 is updated (I've raised it with AWS), but useful to have this bug here with the details.
ISSUE TYPE
- Bug Report
COMPONENT NAME
ecs_taskdefinition
STEPS TO REPRODUCE
ecs_taskdefinition:
state: present
force_create: no
...
containers:
...
- name: ...
secrets: ...
EXPECTED RESULTS
An ecs_taskdefinition call with the same parameters should correctly validate that a task definition revision already exists with the same configuration.
ACTUAL RESULTS
An ecs_taskdefinition with the same parameters (but including secrets config in a containerDefinition) always returns CHANGED, with a new task definition revision created.
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecs.html#ECS.Client.describe_task_definition
Files identified in the description:
If these files are inaccurate, please update the component name section of the description or use the !component bot command.
@Alex-Richman: Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.
Here are the items we could not find in your description:
- ansible version
Please set the description of this issue with this template: https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE/bug_report.md
cc @Java1Guy @jillr @s-hertel @tremble @wimnat click here for bot help
@Alex-Richman Thank you for reporting this! Are you aware if boto3 was fixed? Is this still an issue?
I can confirm this issue. It prevents the update of any secrets when using ecs_taskdefinition.
cc @alinabuzachis @markuman click here for bot help