I’m using Ansible from my Ubuntu Workstation and I have issues with the ec2 module because it need Boto 2.5+ whereas in Ubuntu 12.04 LTS the packaged version is 2.2 (and Server version too I guess).
I did a patch to be able to use the module with previous Boto version but before submiting a pull request I prefer to ask because I’m not sure it’s a good idea.
Pros :
Support Linux distribution who are packaging old Boto versions out of the box. I think Ubuntu LTS versions are widely used. It’s quite frustrating to test a tool and to get an error for the first try.
Don’t break/change anything for Boto version 2.5.0+
Cons :
There is no mistake in Ansible: Documentation says it required Boto 2.5 and it works fine
I didn’t know if other distribution are using old Boto version but for Ubuntu, le LTS will be deprecated in 04-2014 so it’s only a temporary solution
Right now, I only add support to ec2 module but there are other modules who require this Boto version (at least ec2_ami following the documentation)
Do you think it’s a good idea to add this support ? If you want to know the kind of solution I propose, you can check this commit : https://github.com/CharlesBlonde/ansible/commit/255f4a865bf9b228f9856ccb2edcbdf9208cea43
Maybe an intermediate solution is only to check the version and add a module.fail_json(msg=“Your Boto version is too old, You need 2.5.0+”) to prevent a Python traceback and don’t let the user without a solution ?
To be honest, I didn’t read the mention about required version before trying the ec2 module and my first reflex was to look at the source code to understand and bypass this limitation. But if I had a clear message instead of a traceback, I simply did a Boto manual installation to bu up to date
Go ahead and send us a pull request and we’ll review it. My main concern is that while it may work with some functionality on some modules, it may hit an error on some corner cases so we’ll just have to test it.
Ok, I just send a pull request : https://github.com/ansible/ansible/pull/4070
I did some tests with ec2_ami module and even if the documentation says it require Boto 2.5.0+, it’s working fine with Boto 2.2.2 without any changes.
I just ran into this the other day with a VM which only supports 12.04. Though you don’t get the newest version of python-boto from the package repo, you could get the newest version via PIP, which works as well as the Ubuntu packaging system.
Personally, I would rather get just enough from the Ubuntu packages to get me to a point where I can switch over to the language specific packaging tools. I’m not as familiar with the Python package management tools, but for sure I wouldn’t use Ubuntu packages to install things that are handled by Ruby gems.
Just because it’s in the Ubuntu package list doesn’t mean that it’s the best option (or in some cases even a safe option.) I just did a search. Drupal? Rails? Wordpress? I would never use these packages.
My problem with ‘language specific installers’ is that with system packages you get security feeds and patches, stuff you need to setup on your own or laugh trust developers to keep up to date.
I’m not talking about features, which upstream will always have ‘more up to date’, but about tested reliable and secure updates which distro packagers, security researchers and auditors take great pains to keep secure. IIt is very important when your devs are writing web services available to the world that their underlying libraries are appropriately audited and patched.
In the case of boto, you can allow for the assumption that it will always be for traffic initiated on your side so this is not a big concern, I’m stating it as a general rule and not as an inflexible one that can be rationally overridden. Mostly it was a response to the other generality " using pip on Ubuntu is far superior to using the apt packaged versions".
The reality is that it’s not that simple. Using the Wordpress package as an extreme example. I don’t know if it gets security updates, but no matter what the update schedule, it’s probably not quick enough, especially when you are running a popular site which is likely a big target. Again, this is an extreme example to the point of being ridiculous. I don’t think Wordpress should be in the repo, but you have the choice not to use it.
The entire stack from the OS to user facing applications (web applications) is a house of cards. The repo’s manage this pretty well, but there can’t be a one size fits all. I think the “stability” argument for using the distro repo’s has more weight as you are looking more at the systems end of the spectrum and not so much as you get to the more user facing end of the spectrum (Rails, Wordpress.) Another consideration is that the lower levels of the stack are more crucial because more things get built on top of them. As you get to Wordpress or Rails, the only components being built on top of these layers is your code.
Generally I rely on the distro repo for stuff that I don’t need to bother with and then compile my development tools from source (to include the web server and libraries for the programming language I’m working with.) I then use the language specific package management system (Ruby Gems for example) to manage dependencies. In some cases, I need complete control over the version I’m using and Ansible is another example as I’m using 1.3 pulled straight from Github.
In the spirit of Ansible, I can use my playbooks to help shore this stack up. If I break something, then I can make sure I have playbook tasks on hand to roll back changes. If I screw things up beyond repair, then I can use Ansible to bring up a fresh server with everything in place.
However, the problem with Python (more so than Ruby, but probably close to equal with Perl) is that its place on the above mentioned spectrum gets a bit muddy. It’s used heavily for systems level stuff as well as the more user facing stuff (Django for example) and the Python libraries are dependencies for a lot of distro packages. If you use pip then you get into a situation where some packages are managed by pip and some are managed by the distro repo. I don’t know the specifics on how big of an issue this is with the Python ecosystem, but it’s a PITA to deal with for Ruby. I compile Ruby from source and occasionally I slip and install a repo package which installs an older version of Ruby and takes over my path. Again, Ansible to the rescue. I make sure that I have tested everything on a throw-away instance to make sure that I’m not going to run into surprises.
So, if this was a Facebook relationship status, it would be “complicated.” The bottom line is, there is more than one way to do it. If you feel that X way is best for you, then I guess we can’t argue with that.
I can confirm this is all a PITA in python, ruby, php and perl (I'm amazed
how rake and pip make me miss cpan).
It is all about balance. Security, availability, resilience, functionality
and maintainability are what I look at, since I normally work with people
that ONLY care about functionality I tend to overcompensate on the others,
specially since I tend to work with a lot of PII and other confidential
info.
As a preference (or generality) I try to use system packages whenever
possible (security advisories, workarounds and patches made simple!), if
not I try to setup security feeds that will keep me apprised of
vulnerabilities stemming from the versions of the libraries we use,
checking their reputation also (50 CVE entries are not a good start for a
2yr old project) and sometimes even check the source code to get a grasp on
how the author(s) keep quality and security in mind. I don't do this for
EVERY library/package used (I still have 1/2 a shred of sanity I need to
keep ... I think) but those that affect connections, validation, auth,data
access, etc ... mostly where we have vulnerable surface or need the
security.
That said, I know many a business that is 'successfully' run with gaping
security holes all over the place.
All we need to do here is detect that the module is old and print a warning.
Although the current message needs to be tweaked a bit, I’ll reply in the pull request.
I agree system packages are always preferred so this is just something that needs to be done when we can’t write the module to deal with differing versions of the module.
