-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AutoScaling Group tags module #481
Comments
Files identified in the description: If these files are inaccurate, please update the |
A new module to manage ASG tags, analogous to the `ec2_tag` module in `amazon.aws` collection. Fixes ansible-collections#481
A new module to manage ASG tags, analogous to the `ec2_tag` module in `amazon.aws` collection. Fixes ansible-collections#481
A new module to manage ASG tags, analogous to the `ec2_tag` module in `amazon.aws` collection. Fixes ansible-collections#481
A new module to manage ASG tags, analogous to the `ec2_tag` module in `amazon.aws` collection. Fixes ansible-collections#481
Hi @tremble, how do you feel about this PR? |
Generally I prefer the alternative option of adding a "purge" option to the ec2_asg module (defaulting to purge=True, but supporting purge=False for the behaviour @jsok is after). On the whole it's more consistent with our other modules. However, we do have ec2_tag and ecs_tag, so it's not entirely inconsistent. Consider me neither a +1 nor a -1. |
ec2_asg: Add purge_tags to AutoScalingGroups. SUMMARY Add purge_tags to ec2_asg module. Fixes #481. ISSUE TYPE Feature Pull Request COMPONENT NAME ec2_asg ADDITIONAL INFORMATION There was another PR (currently closed) #482 - with similar functionality but I'm not sure if having modules to handle tags for individual services/modules is a good way to have this functionality. It will certainly cause increase in number of modules. Hence tried modifying existing ec2_asg module to be able to do this. This utilizes underlying API calls to: https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DescribeTags.html https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CreateOrUpdateTags.html https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteTags.html Reviewed-by: Alina Buzachis <None> Reviewed-by: Jill R <None> Reviewed-by: Mandar Kulkarni <[email protected]>
ec2_asg: Add purge_tags to AutoScalingGroups. SUMMARY Add purge_tags to ec2_asg module. Fixes ansible-collections#481. ISSUE TYPE Feature Pull Request COMPONENT NAME ec2_asg ADDITIONAL INFORMATION There was another PR (currently closed) ansible-collections#482 - with similar functionality but I'm not sure if having modules to handle tags for individual services/modules is a good way to have this functionality. It will certainly cause increase in number of modules. Hence tried modifying existing ec2_asg module to be able to do this. This utilizes underlying API calls to: https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DescribeTags.html https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CreateOrUpdateTags.html https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteTags.html Reviewed-by: Alina Buzachis <None> Reviewed-by: Jill R <None> Reviewed-by: Mandar Kulkarni <[email protected]>
…le-collections#481) ec2_instance: wait on instance state, rather than status check Attempt to revive ansible-collections#461 (Thanks @overhacked) SUMMARY The await_instances() function was calling module.client('ec2').get_waiter('instance_status_ok') by default, which causes boto3 to wait on the DescribeInstanceStatus api to return "Ok". The status API is linked to EC2's instance status checks, which lag the instance's real state by 3-5 minutes. It's unlikely that most Ansible users who set wait: true want their playbooks to delay until EC2's status checks catch up. The more efficient approach is to use wait_for or wait_for_connection. What is useful, however, is to wait the short period of time necessary for EC2 to move an instance from pending to running. Before this change, the ec2_instance module would wait for an "Ok" status check for newly-created instances before waiting for any other state change. This change makes the default state: present wait for instance_exists, and state: running wait for instance_running. state: started (previously just an alias for state: running) now will wait for instance_status_ok if wait: true. The only, IMHO unlikely, scenario that this is a breaking change for is if an Ansible user had combined state: present/running/started and wait: true and is actually depending on the play to halt until EC2's status checks return OK. Based on my own informal survey of playbooks on GitHub, I did not see anyone using ec2_instance in this way. Most playbooks follow ec2_instance with wait_for or wait_for_connection. ISSUE TYPE Bugfix Pull Request COMPONENT NAME ec2_instance ADDITIONAL INFORMATION Reviewed-by: Jill R <None> Reviewed-by: Alina Buzachis <None> Reviewed-by: None <None>
…-collections#497) Wait for instance to start before attempting to attach a volume SUMMARY Following ansible-collections#481 ec2_vol tests failed because the instances hadn't finished starting before trying to attach botocore.exceptions.ClientError: An error occurred (IncorrectState) when calling the AttachVolume operation: Instance 'i-0d740b81c23f11a4c' is not 'running'. ISSUE TYPE Bugfix Pull Request COMPONENT NAME ec2_vol ADDITIONAL INFORMATION https://7860a9269d0955476c03-81788054a9528b940bcdbd064c8a3746.ssl.cf1.rackcdn.com/488/b02aebad5940f5500e4ccb93c093bc00339b2426/check/ansible-test-cloud-integration-aws-py36_1/110bed5/job-output.txt Reviewed-by: None <None>
SUMMARY
Add a new module
ec2_asg_tag
analogous toec2_tag
to manage tags on AutoScaling Groups.ISSUE TYPE
COMPONENT NAME
ec2_asg_tag
ADDITIONAL INFORMATION
Using
ec2_asg
to manage tags is difficult since you must specify the entire list of tags to manage them.This is cumbersome since you first need to use
ec2_asg_info
to query the current set of tags, munge the result to create a new list of tags that includes or excludes the tags you with to add/remove and callec2_asg
again.A more declarative approach would be to follow the pattern of
ec2_tag
, e.g.:The module would utilise underlying API calls to:
The text was updated successfully, but these errors were encountered: