Hi,
I am executing ansible against a red hat 6.1 machine which I have installed a parallel version of python3.8 which is in /usr/local/bin/python3.8. The problem comes when I try to run any role. or independet playbook. I mean, in the inventories or in the --extra-vars or in ansible.cfg I have already tried to put ansible_python_interpreter=/usr/local/bin/python3.8 and all I get it fine, and the playbook is running but suddenly it comes to some task and jumps the error “ansible-core requires a minimum of Python2 version 2.7 or Python3 version 3.5. Current version: 2.6.6 (r266:84292,”) . The weird thing is that sometimes it runs the tasks (either on localhost or on the red hat machine) and in some other task the error pops up, it is very random. I am using:
It isn’t random. We just haven’t identified the relevant circumstances. You’re going to have to gather more data. Are there some tasks that are more likely to have this occur? Is the RHEL 6.1 machine the only target, or are multiple hosts involved when this happens. I’m curious about the “either on localhost or on the red hat machine” part. Are you saying this happens on the local host (ansible controller) as well as the RHEL 6.1 host?
Are there some tasks that are more likely to have this occur? → No, normal tasks as change the value of a file, add some data into config files and install software (like falcon sensor, antivirus…) , so are write, modify and execute actions.
Yes, it is the only target -l ip_direction
either on localhost or on the red hat machine; with this i trully wanna say thast the error is just occuring on the red hat machine and it doesnot happen on localhost.
What modules are failing? Some modules like yum require the system python interpreter, and they’ll respawn themselves to use /usr/bin/python2 which will then fail, as python2.6 is not supported. If you want to use such an ancient version of RHEL, you’ll have to use an older version of ansible that still supports python2.6.
I get that the yum program is itself an OS-provided python program, so of course it would require the system python, but … ? So the yum Ansible module doesn’t treat /usr/bin/yum like a black box, but uses its internals directly, and respawns itself to do so!? That seems kinda sketchy.
Regardless, would a work-around - for yum at least (on a RHEL that’s so old it could be treated like alien technology) - be to use the command module and run /usr/bin/yum with appropriate parameters? I’m all for upgrades etc., but @valkiriaaquatica has so much working, it’d be a shame to be stopped by a module that’s being too clever. Maybe the yum module needs a working_trumps_clever: true option.
Yum has a public API that ansible uses, so it’s not sketchy at all. The respawn thing only happens when import yum fails, and was apparently added in core 2.11 to allow RHEL 8 to package ansible-core for python3.8 despite the system python being python3.6. None of the package management modules, including the dnf and dnf5 ones that have superseded yum, support calling the package management binary directly. They all use the Python bindings. Ansible modules are written in Python so it makes perfect sense for them to use actual Python APIs when they exist instead of shelling out to other programs.
I get the main idea from @utoddl (no ansible this time).
By the way @gotmax23 I didn’t know that yum was using the API for that Ansible version, that’s why the update also failed on some machines… I tried to modify the module itself and remove the respawn by adding a loop that always takes the path I want from python but it ended up failing. Maybe it’s my turn not to do it with Ansible! a pity haha
Thanks!!! You have been reeally kind
I get that the 