ec2_ami_search

Greetings, I’m a bit new to ansible, but learning the ropes as I go.

The other day I was hoping to use the ec2_ami_search module to grab the appropriate AMI for the ec2 module to use during instance creation. I quickly found out that the ec2_ami_search module is specific to ubuntu and actually doesn’t even query the EC2 API. This clearly didn’t work for us, so I dug into the EC2 API a bit (via boto) to see how we could make this more flexible. Unfortunately, the only way I could find to do this deterministically is to query by full name:

https://gist.github.com/dudeche/c29986e29b61c41fd466

An example task:

  • name: get image
    ec2_ami_get: >
    name=“amzn-ami-pv-2014.03.2.x86_64-s3”
    region=“us-west-2”
    register: image

The reason it’s difficult to drill down via parameters such as architecture, virtualization_type, etc, is due to the fact that AMI names also have additional metadata embedded in them that can’t be queried otherwise (e.g., version, ssd ebs, etc).

The solution we’re going with isn’t all bad, in that I’d rather reference a string that I can read for all regions as opposed to keeping track of specific AMIs. The AMIs we use are consistently named across all regions. I don’t think we’d want to use an AMI where this wasn’t the case. We combine this module with ec2/r53 modules via “variable profiles”.

Anyway, I’d like to make two proposals:

  • ec2_ami_search - make this actually query the EC2 API, but be ok with returning 0 or more results.

  • ec2_ami_get - basically the gist above with proper documentation etc. The code is super simple, so perhaps this doesn’t need to be a module?

Assuming I’m not nuts here, does this sound valuable or of interest to anyone?

Thanks!

-Dan

An additional thought, I thought about just extending the current ec2_ami_search to do something “different” for AMIs that weren’t blessed by Canonical. This seems a bit disingenuous and unclear to me. Ideally the current ec2_search_ami is moved to something like ubuntu_search_ami where it’s much more clear what the module is actually doing.

Anyway, ignore me if I’m being overly pedantic here.

-Dan

So to make this backwards compatible, I’d propose we key off the distro parameter.

The default can be Ubuntu (which is /slightly/ weird) and the other could be something like “general”. We’d have to note in the descriptions which arguments aren’t well fitting together, and make the code raise errors in those cases.