Following up on issue #445, this PR adds more diagnostics to the step that enables fast-launch.
Since the wait step only waited for the state to change to either "enabled", "enabled-failed" or "enabling-failed", but later on the code didn't check the state was indeed "enabled", we could end-up in a situation where the fast-launch step failed on AWS, but the plugin would count it as a success.
Note: I couldn't replicate such a scenario in my tests, but this remains a possibility, so I hope the community will someday share a template that we can adapt to ensure the plugin does take this into account.
Also, added some checks to signal the step is being skipped if no AMI's present in the plugin's state bag, as otherwise the step would silently succeed without doing anything.
Finally, we also fix the acceptance tests, as the AMI we picked for them did not exist anymore, and therefore would always fail.
Following up on issue #445, this PR adds more diagnostics to the step that enables fast-launch.
Since the wait step only waited for the state to change to either "enabled", "enabled-failed" or "enabling-failed", but later on the code didn't check the state was indeed "enabled", we could end-up in a situation where the fast-launch step failed on AWS, but the plugin would count it as a success. Note: I couldn't replicate such a scenario in my tests, but this remains a possibility, so I hope the community will someday share a template that we can adapt to ensure the plugin does take this into account.
Also, added some checks to signal the step is being skipped if no AMI's present in the plugin's state bag, as otherwise the step would silently succeed without doing anything.
Finally, we also fix the acceptance tests, as the AMI we picked for them did not exist anymore, and therefore would always fail.