3 ms·

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

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.

Spivak 6y ago
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".
- ofrzeta 6y ago
  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?
  - Spivak 6y ago
    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.

Spivak 6y ago

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".

ofrzeta 6y ago
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?
- Spivak 6y ago
  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.