Speed up 'yum' related tasks?

[John Oliver]

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?

[Michael DeHaan]

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/a9ca0946-86be-45c3-bbea-5d9dae157972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael DeHaan]

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.

[John Oliver]

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?

[Michael DeHaan]

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 :)

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/cd4972d2-0f88-4e35-bf70-e8162e5214b8%40googlegroups.com.

[Greg DeKoenigsberg]

On Aug 6, 2014 6:05 PM, "Michael DeHaan" <mic...@ansible.com> wrote:
>
> 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. :)

> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwg-3CcuWNU7b4bSXTaeNLnfWd0NP5aw2zO8Z5We-pMZw%40mail.gmail.com.

[John Oliver]

WOW!  Disabling fastestmirror made a HUGE difference!  It wouldn't let me remove the package, though... it's a dependency for yum :-(