The ‘yum’ module is pretty slow for me. That might be an artifact from running my play books against a VM, but running ‘yum install a b c d e f’ is a lot faster than:
- name: Install PHP packages
yum: name={{item}} state=latest
with_items:
- php
- php-common
- php-xml
- php-mbstring
- php-imap
- php-pdo
- php-pgsql
- php-mcrypt
With one package, I could find a file that gets installed for that package, look for it, and if that fails then do the install. But that’s a lot harder to do with a bunch of packages like above unless I want to duplicate the task for each item. I can accept it taking several minutes when it actually has to install those packages, but when they already exist, it STILL takes several minutes, a lot longer than using the native yum command.
Is there anything that can be done to the module, either by me or as a feature request / bug fix, that can let it see if the packages already exist and move along?
Yeah so even though it groups things in one transaction, it calls repoquery a lot because it wants to decide to be idempotent and not run the “update” commands for things it should not need to update.
Seth believed this was the right way to go (RIP - you were awesome my friend and helped us immensely!), and I initially did too.
However, I think it’s worth revisiting.
We should be able to call directly to yum update and then check whether it did anything, and I’m cool with that.
However, there’s one catch - check mode. The existing path may need to live on from check mode unless the yum system can do it cleanly.
Note we always avoided the Yum API for hard things, because it tends to be a little hairy between versions, particularly when Yum-RHN plugin was installed.
Mostly all due to yum RHN plugin.
Also, be sure you have yum fastestmirror uninstalled, it usually lies 
And if you have PackageKit installed, remove it, since it can occasionally grab a lock.
Also, be sure you have yum fastestmirror uninstalled, it usually lies
And if you have PackageKit installed, remove it, since it can occasionally grab a lock.
If by “occasionally” you mean “seemingly continuously”, yes.
Thanks, I don’t have PackageKit installed, but I do have fastestmirror… I’ll try without. Does yum just do some kind of round-robin without it?
With Fedora I believe mirrormanager will pick something good for you based on GeoIP. There’s even some cool magic for things like IBM internal mirrors if you work for IBM.
Not sure about how CentOS works, but EPEL should be using this too.
The issue is fastestmirror tends to take a while to figure out which is fastest
WOW! Disabling fastestmirror made a HUGE difference! It wouldn’t let me remove the package, though… it’s a dependency for yum 