Comment by Spivak | Hacker News Reader

Comment by Spivak | Hacker News Reader

This seems like a lot of work for such a small problem in Ansible that can actually be fixed without any patches. Here's an example.

    - name: Pretend to install stuff.
      debug: var=item
      with_items: [git, httpd, vim]
      when:
        - "'all' in ansible_run_tags or item in ansible_run_tags"
        - item not in ansible_skip_tags
      tags: always

If you run without any tags it will install everything and if you specify --tags=git it will only install git and if you specify --skip-tags=vim it will do the correct thing.

Ref: https://docs.ansible.com/ansible/latest/reference_appendices...

And in the specific case of installing packages you can speed this process up dramatically with something like the following without having to use tags.

    - name: Probe the host for installed packages.
      package_facts:

    - name: Install packages.
      package: name={{ item }}
      with_items: [git, httpd, vim]
      when: item not in ansible_facts.packages

But this itself is really inefficient too because you're still calling the module for every package instead of calling the module once with all the packages. Older versions of Ansible did this automatically but it was super magic so it's probably better that it was removed. We can do it ourselves though.

    - name: Install packages.
      package: name={{ to_install }}
      vars:
        packages: [git, httpd, vim]
        to_install: "{{ packages | difference(ansible_facts.packages) | list }}"

Now you've shown three different methods to achieve the goal where the third version has become sufficiently convoluted to make it hard to understand.

And how is an Ansible user supposed to know what's more efficient and what are the side effects of calling the packages with name={{item}} or a list variable? The documentation of ansible.builtin.package for one doesn't seem to supply any indication of it.

Fair, I can make the 3rd one more readable. I figured the extra vars would actually help make it clearer. Guess not.

    - name: Install packages.
      package: 
        name: [git, httpd, vim] | difference(ansible_facts.packages) | list

This isn't something super specific to Ansible, it's the same story all over when libraries have a "bulk" or "batch" api so that you don't have to iterate over operations with lots of setup. The package/yum/apt/dnf modules happen to take lists as arguments since you can run "yum install a b c" faster than "for p in a b c; do yum install $p; done".

Ok, that's a valid point. Naively I think a user could also expect the {{items}} to be expanded in the package module but someone who has used Ansible would probably be familiar with the "with_items" idiom.

Also I was confused by your claim that your second version was sped up dramatically although it is still using "with_items". Is this due to the use of facts instead of tags?

The problem the OP was facing was when you had a loop like

    - name: Install packages
      package: name={{ item }}
      with_items: "{{ loooong_list_of_packages }}"

and most of the packages are already installed then you're spending most of the loop running the package module just for it to come back any say 'ok'. Hence why the author wanted to use tags to limit the run to specific packages.

Rather than doing that you can run package_facts once to get a list of all the installed packages and skip all the module invocations you know won't be changed entirely. You can't do this in general because on a totally unknown system something exteranl might mess with packages between your fact gathering and the install but on your known systems this is almost always fine.

Some cool hacks here, thanks for sharing!

Reply on news.ycombinator.com