Closed bedge closed 2 years ago
Files identified in the description:
plugins/modules/ec2_asg.py
](https://github.com/['ansible-collections/amazon.aws', 'ansible-collections/community.aws', 'ansible-collections/community.vmware']/blob/main/plugins/modules/ec2_asg.py)If these files are inaccurate, please update the component name
section of the description or use the !component
bot command.
cc @garethr @jillr @markuman @s-hertel @tremble click here for bot help
The purge_tag
parameter with default true was released with 3.2.0 and revertet to defaults false in 3.2.1
This is why I expect ansible change only what is specified.
That is the behaviour when using purge_tags: false
.
And it is backwards compatible, because the previous version wasn't able to purge tags that were not specified.
Closed via https://github.com/ansible-collections/community.aws/pull/1064
Released in 3.2.1
Summary
Using
default=True
for the newpurge_tags
field, 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: False
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.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.
Also, note that this case 2 fails in earlier versions that didn't have the
purge_tags
element.Expected Results
In case 1 above, the new default for
purge_tags: True
causes 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