Removing collections

Hello All,

I have an Ansible server with collections that are stored under a user context in “/home/user/.ansible/ansible_collections/” in addition to the collections for all users that are stored in “/usr/lib/python3/dist-packages/ansible_collections/”. I found that there are some duplicates of collections, such as “ansible.windows” that are different versions. In order to mitigate the risk of running playbooks using the wrong version of a collection, I want to remove the collections that are installed under a user context.

Unfortunately, I found that there isn’t a remove argument for “ansible-galaxy collection”. And I didn’t find anything in the Ansible documentation or anything definitive in this Google group, nor doing Google searches or ChatGPT. It is possible that deleting the specific folders under /home/user/.ansible/ansible_collections/ would work. But I don’t know if that could have unintended consequences. So, I would like to get some confirmation from anyone who has experience with this or knows where it is documented.

Does anyone know what the best practice is for removing installed collections?

Also, I have submitted an issue for the correct method to be documented at: https://docs.ansible.com/ansible/latest/collections_guide/index.html#using-ansible-collections. It will probably take a while for that issue to be taken on and resolved though.

Best regards,
Eric

Generally, I simply do a “$ rm -rf /home/user/.ansible/ansible_collections/” to force a collection refresh. You can also just remove like that, the collection causing issues.

Another strategy is to force the installation, using --force, which will remove the old version and install the new latest one.

That beings said, I don’t think there is a risk of running the wrong version. The presence of different version is probably because one collection depends on version X and another one depends on version Y. So the first one will use X and the second will use Y.

I don’t have a silver bullet, but to avoid surprises with collections in multiple locations, you can hard code the collections path in your ansible.cfg.
We use ‘ansible-core’ (not ‘ansible’) from a python venv, and when setting that up, we install the collections in there:

ANSIBLE_COLLECTIONS_PATH=$(python -c “import site; print(site.getsitepackages()[0])”) ansible-galaxy collection install -r galaxy-requirements.yml

With this method you end up with the same structure as you would when pip installing ‘ansible’, but without all the collection bloat that comes with that.

Thanks for your response. I will test doing simple folder deletion in a test environment before I try it in production.

An example of why we want to make sure that we are running a particular version is that there have been bug fixes in a newer version of the ansible.windows collection to fix issues with the win_updates module. With the previous version of ansible.windows, we had a lot of issues with the win_updates module hanging with errors on a Windows server and never recovering. So, we would then have to stop the playbook and rerun, hoping that it would run cleanly. By making sure that there is no chance of Ansible using the older version, we are guarding against the having playbook runs fail due to those bugs. Those failures were costly because some of those playbook runs are in tight maintenance windows.

I know that we can set the collections path in ansible.cfg to avoid Ansible using the wrong version. But we still want to remove the collections that are duplicated and don’t need to be there in order to have a cleaner environment. The cleaner it is, the easier it is for everyone to maintain.

Thank you. I will certainly make sure that the collections path is defined in ansible.cfg. And we often do run Ansible from a venv. But it is not in this case.

I also appreciate the tips on installing ansible-core to avoid collection bloat and setting the ANSIBLE_COLLECTIONS_PATH. Now that I have seen all the junk comes with the ‘ansible’ package, I expect that ‘ansible-core’ with a well-curated requirements.yml file will become the standard.