Skip to content
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

Closed
jsok opened this issue Mar 16, 2021 · 3 comments · Fixed by #960
Closed

AutoScaling Group tags module #481

jsok opened this issue Mar 16, 2021 · 3 comments · Fixed by #960
Labels
feature This issue/PR relates to a feature request has_pr

Comments

@jsok
Copy link

jsok commented Mar 16, 2021

SUMMARY

Add a new module ec2_asg_tag analogous to ec2_tag to manage tags on AutoScaling Groups.

ISSUE TYPE
  • Feature Idea
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 call ec2_asg again.

A more declarative approach would be to follow the pattern of ec2_tag, e.g.:

- name: Ensure tags are present on an ASG
  community.aws.ec2_asg_tag:
    resource: my-auto-scaling-group
    state: present
    tags:
      - environment: production
        propagate_at_launch: true
      - role: webserver
        propagate_at_launch: true

- name: Ensure tag is absent on an ASG
  community.aws.ec2_asg_tag:
    resource: my-auto-scaling-group
    state: absent
    tags:
      - environment: development

The module would utilise underlying API calls to:

@ansibullbot
Copy link

Files identified in the description:
None

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibullbot ansibullbot added feature This issue/PR relates to a feature request needs_triage labels Mar 16, 2021
jsok added a commit to jsok/community.aws that referenced this issue Mar 17, 2021
A new module to manage ASG tags, analogous to the `ec2_tag` module in
`amazon.aws` collection.

Fixes ansible-collections#481
jsok added a commit to jsok/community.aws that referenced this issue Mar 19, 2021
A new module to manage ASG tags, analogous to the `ec2_tag` module in
`amazon.aws` collection.

Fixes ansible-collections#481
jsok added a commit to jsok/community.aws that referenced this issue Mar 19, 2021
A new module to manage ASG tags, analogous to the `ec2_tag` module in
`amazon.aws` collection.

Fixes ansible-collections#481
jsok added a commit to jsok/community.aws that referenced this issue Mar 19, 2021
A new module to manage ASG tags, analogous to the `ec2_tag` module in
`amazon.aws` collection.

Fixes ansible-collections#481
@alinabuzachis
Copy link
Contributor

Hi @tremble, how do you feel about this PR?

@tremble
Copy link
Contributor

tremble commented Apr 19, 2021

@alinabuzachis,

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.

@markuman markuman mentioned this issue Feb 1, 2022
1 task
softwarefactory-project-zuul bot pushed a commit that referenced this issue Mar 11, 2022
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]>
alinabuzachis pushed a commit to alinabuzachis/community.aws that referenced this issue Mar 11, 2022
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]>
alinabuzachis pushed a commit to alinabuzachis/community.aws that referenced this issue May 25, 2022
…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>
alinabuzachis pushed a commit to alinabuzachis/community.aws that referenced this issue May 25, 2022
…-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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature This issue/PR relates to a feature request has_pr
Projects
None yet
4 participants