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

ec2_instance: wait on instance state, rather than status check #481

Merged

Conversation

tremble
Copy link
Contributor

@tremble tremble commented Aug 28, 2021

Attempt to revive ansible-collections/community.aws#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

@ansibullbot
Copy link

@ansibullbot ansibullbot added WIP Work in progress bug This issue/PR relates to a bug module module needs_triage owner_pr PR created by owner/maintainer plugins plugin (any type) labels Aug 28, 2021
@overhacked
Copy link

Hello, again, everyone! It appears that there are no blockers for this PR other than waiting on a major release because of the potential (but unlikely) breaking change. See ansible-collections/community.aws#461 (comment).

@markuman also asked if this PR might address #469. I think that changing ec2 instance type is potentially fraught with enough testing issues that I'd rather tackle it in a separate PR. If there's agreement that this PR is ready to merge, then I could stack another PR on it to address the changing instance type. Thanks @tremble, for lighting a fire under me by reopening this. That's great maintainership!

@tremble
Copy link
Contributor Author

tremble commented Sep 3, 2021

Hi @overhacked,

when I checked the integration tests weren't passing. I need to dig into why but haven't had much free time this week.

@ansibullbot ansibullbot added integration tests/integration tests tests and removed owner_pr PR created by owner/maintainer labels Sep 3, 2021
overhacked and others added 6 commits September 3, 2021 11:04
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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#reporting_status), 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`.
In some cases, we need to branch based on desired
EC2 instance state. In others, on desired module state.

Some CI checks were failing due to not checking the
right value. Renamed and/or assigned local variables
in a few critical functions here to be clear on which
state we are referring to.
Added a `force_wait` parameter to `await_instances()`
Using it to await `instance_exists` when creating new
instances before modifying them, because
`diff_instance_and_params()` can fail if it runs too soon
before the EC2 API is consistent.
@tremble tremble force-pushed the ec2_instance/state_present branch from b680792 to cf206df Compare September 4, 2021 17:02
@tremble tremble force-pushed the ec2_instance/state_present branch from cf206df to 3cda932 Compare September 4, 2021 17:41
@tremble tremble changed the title [WIP] ec2_instance: wait on instance state, rather than status check ec2_instance: wait on instance state, rather than status check Sep 4, 2021
@tremble tremble force-pushed the ec2_instance/state_present branch from 3cda932 to 1e45fd8 Compare September 5, 2021 06:22
@alinabuzachis
Copy link
Collaborator

recheck

1 similar comment
@tremble
Copy link
Contributor Author

tremble commented Sep 6, 2021

recheck

Copy link
Collaborator

@jillr jillr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with the changelog nit. This is a really nice improvement, thanks @tremble!

changelogs/fragments/481-ec2_instance-wait_sanity.yml Outdated Show resolved Hide resolved
@tremble
Copy link
Contributor Author

tremble commented Sep 7, 2021

Thanks for the initial work on this @overhacked. If CI plays ball, hopefully we'll be able to get this in place for the 2.0.0 release (RealSoonNow...)

@jillr

This comment has been minimized.

2 similar comments
@jillr

This comment has been minimized.

@tremble
Copy link
Contributor Author

tremble commented Sep 8, 2021

recheck

@tremble tremble added the gate label Sep 8, 2021
Copy link
Contributor

@ansible-zuul ansible-zuul bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@tremble tremble added gate and removed gate labels Sep 8, 2021
@ansible-zuul ansible-zuul bot merged commit ad7a0eb into ansible-collections:main Sep 8, 2021
ansible-zuul bot pushed a commit that referenced this pull request Sep 11, 2021
Wait for instance to start before attempting to attach a volume

SUMMARY
Following #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>
@tremble tremble deleted the ec2_instance/state_present branch November 26, 2021 12:43
abikouo pushed a commit to abikouo/amazon.aws that referenced this pull request Sep 18, 2023
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]>
abikouo pushed a commit to abikouo/amazon.aws that referenced this pull request Sep 18, 2023
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]>
abikouo pushed a commit to abikouo/amazon.aws that referenced this pull request Oct 24, 2023
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue/PR relates to a bug community_review integration tests/integration module module plugins plugin (any type) tests tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants