Molecule Destroy EC2 instances it did not create.

[jolillie]

Hello,

I have ran into a weird issue where when I run molecule create -s aws_ec2 I run into the following error:

FAILED! => {
    "msg": "The task includes an option with an undefined variable. The error was: {{ item.image or platform_generated_image_id }}: {{ (ami_info.results[index].images | sort(attribute='creation_date', reverse=True))[0].image_id }}: 'dict object' has no attribute 'images'\n\nThe error appears to be in '/molecule/aws_ec2/create.yml': line 201, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n    - name: Create ephemeral EC2 instance(s)\n      ^ here\n"
}

Then when I run molecule destroy -s aws_ec2 molecule ends up terminating an EC2 instance that it did not create.

I have been able to recreate this issue twice now. Let me know what logs or other information I can send to resolve this issue.

System Information:

ansible --version && molecule --version

 32527 1665089931.56849: starting run
ansible [core 2.13.4]
  config file = None
  configured module search path = ['/Users/Jon.Lillie/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/Cellar/ansible/6.4.0/libexec/lib/python3.10/site-packages/ansible
  ansible collection location = /Users/Jon.Lillie/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.10.7 (main, Sep 15 2022, 01:51:29) [Clang 14.0.0 (clang-1400.0.29.102)]
  jinja version = 3.1.2
  libyaml = True

molecule 4.0.1 using python 3.10 
    ansible:2.13.4
    delegated:4.0.1 from molecule
    docker:2.0.0 from molecule_docker requiring collections: community.docker>=3.0.0-a2
    ec2:0.4 from molecule_ec2
    vagrant:1.0.0 from molecule_vagrant

[dlouzan]

I just experienced this and was saved by our instance-termination flag on the running instances. There's no need to run a create first, just running a destroy as first command will identify an inventory consisting of any available instance on the AWS account, instead of failing.

This was a dev account, and in any case, one should setup IAM rights to forbid access to other unrelated containers, but this is pretty dangerous default behaviour. It makes really easy to inadvertently delete everything on an AWS account.

[jolillie]

@dlouzan Agreed. I ended up not using this at all and instead used the delegated and terraform to build and destroy the infrastructure I was using for testing. I am just glad someone else ran into a similar issue to mine.

[dlouzan]

@ssbarnea @jolillie In theory #170 should cover this one too I think?

/cc @nejch