purge_tags: True default causes version incompatibilities and strips all ASG tags #1133
Closed
1 task done
Comments
|
Files identified in the description:
If these files are inaccurate, please update the |
ansibullbot
added
bug
|
The
That is the behaviour when using |
|
Closed via #1064 |
abikouo
pushed a commit
to abikouo/community.aws
that referenced
this issue
Oct 24, 2023
…-collections#1133) Add metrics and extended_statistic keys to cloudwatch module Signed-off-by: GomathiselviS [email protected] To support https://issues.redhat.com/browse/ACA-638 , a new key metric ( a list of dicts) is added to the cloudwatch module SUMMARY ISSUE TYPE Feature Pull Request COMPONENT NAME cloudwatch.py ADDITIONAL INFORMATION Reviewed-by: Bikouo Aubin <None> Reviewed-by: Gonéri Le Bouder <[email protected]> Reviewed-by: Mike Graves <[email protected]> Reviewed-by: GomathiselviS <None> Reviewed-by: Alina Buzachis <None>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Using
default=Truefor the newpurge_tagsfield, causes any ansible action on an already existing ASG to strip all its tags.https://github.com/ansible-collections/community.aws/pull/960/files#diff-629ed6761ca29636823559acc0c8f4aaa6c405c299e596ac5cddacc49447f569R227
This is a "bad thing" for ASGs especially because the ASG tags are used to convey context information to the instances created by the ASG.
Note also that
purge_tags: Falseis NOT backwards compatible, because that field didn't exist in previous versions, so you need 2 different cases depending on which side of this version you fall on.
Given that the purge_tags things seems to have propagated to many AWS assets, all in slightly different releases, one needs to account for this on a case by case basis depending on when the purge_tags was introduced into each module.
If the default had been purge_tags=False, none of this would be an issue.
There would have been no changes required as the new behavior would match the old.
I would expect ansible to alter "only what is specified" and expect the rest to remain as-is.
Issue Type
Bug Report
Component Name
ec2_asg
Ansible Version
Collection Versions
AWS SDK versions
Configuration
OS / Environment
Ubuntu 18.04.6 LTS
Steps to Reproduce
Case 1)
Existing use case to scale in/out an ASG, and touch nothing else:
With the current default of
purge_tags = true, the above and strips all tags.Given that most ASG tags are used to propagate context information to the ec2 instances, this now destroys all context information for the ASG and the instances it creates have no information about the runtime context.
Case 2)
This now requires adding the purge_tags: False everywhere where tags could be impacted.
name: "{{ item.auto_scaling_group_name }}"
min_size: "{{ count }}"
max_size: "{{ count }}"
desired_capacity: "{{ count }}"
purge_tags: False <----- This is now needed everywhere tags are used to say "leave alone" ?
region: eu-central-1
This is the ONLY case where one has to specify a non-default option just to say: "leave alone".
Also, note that this case 2 fails in earlier versions that didn't have the
purge_tagselement.Expected Results
In case 1 above, the new default for
purge_tags: Truecauses any ansible action on an already existing ASG to strip all its tags.This is a "bad thing" for ASGs especially because the ASG tags are used to convey context information to the instances created by the ASG.
Why was default=True chosen, for a new field that no one was using previously, deemed a good idea?
Now, everything that touches any asset that uses tags MUST now add a purge_tags: False just to leave things as they are??
This is not "principle of least surprising behavior"?
The code in case 2 is now required to get ansible to NOT destroy all tags of existing ASGs.
Note also that
is NOT backwards compatible, because that field didn't exist in previous versions, so you need 2 different cases depending on which side of this version you fall on.
One has to know if the runtime is using a release before or after this PR and adapt accordingly.
https://github.com/ansible-collections/community.aws/pull/960/files#diff-629ed6761ca29636823559acc0c8f4aaa6c405c299e596ac5cddacc49447f569R227
That is not backwards compatible
Given that the purge_tags things seems to have propagated to many AWS assets, all in slightly different releases, one needs to account for this on a case by case basis depending on when the purge_tags was introduced into each module.
If the default had been purge_tags=False, none of this would be an issue.
There would have been no changes required as the new behavior would match the old.
I would expect ansible to alter "only what is specified" and expect the rest to remain as-is.
My use case may differ from what others are doing and this may be the source of for problem -
I am not provisioning with ansible, I am using ansible to alter state of existing assets provisioned by terraform.
This is why I expect ansible change only what is specified.
Actual Results
Both cases are above, hard to separate and explain.
Code of Conduct
The text was updated successfully, but these errors were encountered: