Fixing Python and Ansible Issues on RHEL 8
I've recently been running into an issue at work regarding RHEL 8.10 hosts and Ansible - specifically with Automation Platform. I'll go over the issue I encountered, what I found to be the root cause of the issue, and an explanation of the solution I found. My hope is that someone else will come across it and be saved time and energy as finding the right angle to approach the problem from took me quite a while.
If you just want the quick version of the fix, here it is:
- Install Python 3.9 on the target host.
dnf install python39is enough. - Use Ansible 2.21. The execution environment is
ghcr.io/ansible-community/community-ee-base:2.21.0-1
I encountered the issue while trying to run a role on one of our RHEL 8.10 servers at work. I was trying to run a role that included both ansible.builtin.package (though really it was running ansible.builtin.dnf) and community.general.rhsm_subscription. The playbook would fail at the rhsm_subscription task with the following error (greatly trimmed for clarity):
SyntaxError: future feature annotations is not defined
RHEL 8.x uses Python 3.6 as the default, system-wide Python version. Unfortunately, Ansible removed support for Python 3.6 in version 2.17 and many collections followed suit.
It wouldn't be unreasonable to assume that you could fix this by installing a newer version of Python. RHEL 8.10 offers 3.8, 3.9, 3.11, and 3.12 in the repositories. However, attempting to install a different version of Python gave me an error at the dnf task (again, edited for clarity):
Could not import the dnf python module using /usr/bin/python3.12 . Please install python3-dnf package or ensure you have specified the correct ansible_python_interpreter. (attempted ['/usr/libexec/platform-python', '/usr/bin/python3', '/usr/bin/python'])
This put me in an unfortunate situation. The python3-dnf package is only available for Python 3.6, and attempting to install the other version via pip3.9 will error out and say to use the distribution's installer instead.1
In retrospect, I could have overridden the Ansible interpreter version just for this step using a task-level override for the ansible_python_interpreter variable.
My solution ended up, after much trial and error of attempting to use older versions of the collections, to use the recently released ansible-core 2.21 as the basis for my execution environment. Per this forum thread, Ansible 2.21 fixed the issue with dnf with the caveat that you now need at least Python 3.9 on the target.