-
Notifications
You must be signed in to change notification settings - Fork 23.7k
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 test cleanup #63708
ec2_instance test cleanup #63708
Conversation
@tremble, just so you are aware we have a dedicated Working Group for aws. |
23a91ca
to
3e241a8
Compare
I believe the code's good at this point, so reviews would be appreciated. Over the course of the next couple of hours I'm going to try to trigger additional test runs in the Shippable environment by rebasing, cleaning up unused/duplicate files and tweaking the documentation a little bit. However, I believe I've tracked down the cause of the instability... |
6f5043f
to
29940c3
Compare
@tremble This PR was evaluated as a potentially problematic PR for the following reasons:
Such PR can only be merged by human. Contact a Core team member to review this PR on IRC: |
c15cf05
to
e227f65
Compare
e227f65
to
a053a64
Compare
38e05ca
to
2deeb33
Compare
@s-hertel I'll push more rebases through out the day, but I think the tests are now consistently passing. |
2deeb33
to
00fc780
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good. Thanks for cleaning up so much.
test/integration/targets/ec2_instance_a/tasks/external_resource_attach.yml
Outdated
Show resolved
Hide resolved
b8acac4
to
0733f38
Compare
The test
|
0733f38
to
cd1f132
Compare
Thanks @tremble! |
SUMMARY
Attempts to stabilise the ec2_instance tests (see also #58650)
CC: @s-hertel
ISSUE TYPE
COMPONENT NAME
lib/ansible/modules/cloud/amazon/ec2_instance.py
test/sanity/ignore.txt
ADDITIONAL INFORMATION
Found one 'interesting' quirk - 'wait' only waits for the completion of actions initiated by the specific call.
If you pass a filter or multiple instance_ids and they're already transitioning to the new state, then 'wait' will return straight away rather than waiting for the instances to reach the desired state. This is problematic when dealing with mass-removals where you need to wait for dependencies to be 'gone' before deleting them (eg waiting on instance termination before deleting ENIs/volumes)