# ec2\_ami\_find fails on ubuntu 15.04, boto==2.34 **URL:** \ **Category:** Ansible Project\ **Tags:** ubuntu\ **Created:** [October 21, 2015, 11:55pm UTC](https://forum.ansible.com/t/ec2-ami-find-fails-on-ubuntu-15-04-boto-2-34/19584 "2015-10-21T23:55:08Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![viper233](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/viper233/32/2060_2.png) [@viper233](https://forum.ansible.com/u/viper233)\ **Post date:** [October 21, 2015, 11:55pm UTC](https://forum.ansible.com/t/ec2-ami-find-fails-on-ubuntu-15-04-boto-2-34/19584/1 "2015-10-21T23:55:08Z")
‘creationDate’: image.creationDate, AttributeError: ‘Image’ object has no attribute ‘creationDate’ The version of boto installed on ubuntu 15.04 is only 2.34 and the image object doesn’t have the creationDate attribute. Its difficult to install updated python modules on Debian/Ubuntu due to the feature that doesn’t allow you to uninstall older versions of OS (python module) package installs and it seems to only reference the earlier version of boto. I removed the python-boto package apt-get remove python-boto though this isn’t really a permanent solution. Does anyone have a better solution to this? (apart from upgrade to wily) What’s the overall approach to managing different major OS release versions of python modules for Ansible version 2.0? 1. remain using the older version of Ansible and use a virtualenv if you want to use v2.0? 2. Make new modules aware of older python modules? 3. Not being a python programmer is it possible to check for a required version of a python module? This seems like a nice middle ground between options 1 & 2 and could be a nice feature moving forward. It shouldn’t be overly time consuming to test either. Should these modules be rewritten eventually to support boto3? (get ready for collections!!!) it seems this is the approach for some of the extra modules. Using the latest devel v2.0. on Ubuntu 15.04