Trade offs regarding installing control machine via rpm versus pip

Archives Ansible Project
1

I appreciate the plethora of options for installing ansible control machine, however I’d appreciate insight into why someone might prefer installing it via rpm versus pip even more.

My offhand thoughts:

  1. pip would allow for multiple versions and/or dependencies upon a single machine whereas rpm would force global adherence
  2. both methods support caching and repositories so no blatant advantage there
  3. pip is portable and consistent experience across various operating systems versus rpms only working on the Redhat family of OSes
    Thanks!
2

1+ afeller comments.

3

First i would compare ‘language specific’ vs OS package, rpm and pip are not the only options, rpm + deb cover most distributions but there are more options than just those 2. This would change #3 in that portability depends on OS package availability, which at this point in time is probably not an issue.

Another issue with pip #3 is that ‘not all pip are equal’, many systems ship with older versions of pip that either have bugs or behaviors that differ from the latest and cause issues with installation, specially with binary dependencies. The ‘easy’ fix is to always upgrade pip first, but many users are not aware of this until they are already hitting the problem.

One issue I see OS packages being preferable is testing and auditing. Most testing and auditing targets OS distributions, while language specific installers bypass the normal OS versions of software and make it almost impossible to test and audit consistent versions of what a user will have installed. Sticking with the OS package will at least give you some level of guarantee that it has been tested and audited in a consistent manner.

The other issue is ‘predictability’, rolling releases aside, OS packages normally guarantee a version and compatibility of the software while keeping up to date with security and bug patches. Language specific package managers normally only have ‘latest’ which can introduce new features, change in API, etc, they don’t normally have a ‘bug and security fixes only’ capability.
You ‘can’ freeze to a version and make it predictable, but then you cut yourself from access to bug and security fixes, not freezing a version takes you back into a state that can introduce a surprise feature and/or API change.

The main draw for pip and any language specific package manager is ‘speed to market’, the releases to these are normally handled by the original software developer and don’t go through the lengthier process to package for an OS, also you get the new features right away, you don’t have to wait for the next OS release. As stated above this can also be a downside, depends on what your needs are and the context into which you deploy.

I’m not saying which one is better, just that they both have their upsides and downsides. Choosing each one is very dependent on the environment in which you are going to use the software.
If what matters is having the newer feature and being able to bring value faster, use the language specific package.
If you are require predictability, auditability and the most thorough testing, you’ll have to stick with the OS package.

4

As solid of a response including objective as I could hope for; thanks brian!

5

I forgot to add, that both options allow for 'corraling' different
versions, python has virtualenv and pep370 (most scripting languages
have a variation of this) while at OS level you have
VMs/containers/chroots and similar. The OS level corral does normally
require more work and overhead, but it is possible to have multiple
versions easy accessible either way. There are even package
managers/OS dedicated to offer this type of siloing like snap, nix,
coreos, qubes, etc (list is too long and I don't know them all, but
plenty of options here).

6

Thanks for the addendum there, Brian! I think though that “require more work and overhead” might be underselling the effort and ongoing maintenance cost of corralling OS distributions for anything but containers.

The other significant difference is only the latest version of Ansible is available via epel unless you pull directly from Ansible’s yum repository, which no one wants all of us to do. This is especially problematic as all the various Ansible-in-container solutions (ansible-runner, apb-base, playbook2image) don’t allow end user to specify version they need nor are the images tagged in a way to allow people to control when they upgrade. In short, this requires people to build their own in some form or fashion.

7

Thanks for the addendum there, Brian! I think though that “require more work and overhead” might be underselling the effort and ongoing maintenance cost of corralling OS distributions for anything but containers.

I kept it vague because the effort needed depends a lot on the experience of the user. I’m used to managing/maintaining hundreds if not thousands of machines/images/containers/vms so I can construct a few plays to handle that easily, most people are not me (thankfully).

A 3rd way to install/maintain software, that we didn’t address, is ‘from source’ instead of ‘from official/3rd party repos’, most package managers allow for the creation of custom packages (rpm/deb/etc) in case you don’t want to use SCM directly. Also, pip can do this, but most language based installers cannot.

Advantages are ‘really cutting edge’ with latest features and bug fixes, disadvantages mostly are a more extreme version of the same ones you have with a ‘language specific’ installer: no comprehensive auditing/testing aside from what authors run on the code when committing it. I really don’t recommend this except for people that actually plan on contributing to the project by doing early testing, documenting and even development or those that follow the YOLO philosophy in automation (really, DON’T do this).