interpreter_python set to auto_legacy not working as expected #77840
Comments
|
Files identified in the description: If these files are incorrect, please update the |
ansibot
added
affects_2.12
bug
|
Additional info: Now the "discovered_interpreter_python" is "/usr/bin/python" and that is even with "auto_silent" or "auto_legacy". Did something change inbetween these two releases regarding the handling of "discovered_interpreter_python"? |
|
Please run your playbook with at least I see you ran with |
|
You can find the full log (-vvv) here: |
Relevant Logs...
|
|
Ok, after a whole lot of testing, I've been able to verify this. It only happens if the distro is not listed in Ultimately the change was introduced in fa7482c Based on what I now see, this seems both partly expected, and partly unexpected. The reason that
I think we may need something like this to resolve the problem: diff --git a/lib/ansible/executor/interpreter_discovery.py b/lib/ansible/executor/interpreter_discovery.py
index e821b9beec..32961155c2 100644
--- a/lib/ansible/executor/interpreter_discovery.py
+++ b/lib/ansible/executor/interpreter_discovery.py
@@ -112,11 +112,12 @@ def discover_interpreter(action, interpreter_name, discovery_mode, task_vars):
family = OS_FAMILY_LOWER.get(distro.lower().strip())
- version_map = platform_python_map.get(distro.lower().strip()) or platform_python_map.get(family)
- if not version_map:
- raise NotImplementedError('unsupported Linux distribution: {0}'.format(distro))
+ version_map = platform_python_map.get(distro.lower().strip()) or platform_python_map.get(family) or {}
- platform_interpreter = to_text(_version_fuzzy_match(version, version_map), errors='surrogate_or_strict')
+ try:
+ platform_interpreter = to_text(_version_fuzzy_match(version, version_map), errors='surrogate_or_strict')
+ except Exception as e:
+ platform_interpreter = None
# provide a transition period for hosts that were using /usr/bin/python previously (but shouldn't have been)
if is_auto_legacy:The above diff needs expanded to do a few extra things:
Perhaps instead of setting |
mattclay
added
P3
|
Thank you for your testing. Looking forward to a solution. |
|
Exact same issue on multiple SLES clients |
|
Same issue here, SLES clients. |
|
I managed to get it working by patching ubuntu:
'14': /usr/bin/python
'16': /usr/bin/python3
+ suse:
+ '12': /usr/bin/python2.7
+ '15': /usr/bin/python3
version_added: "2.8"
# FUTURE: add inventory override once we're sure it can't be abused by a rogue target
# FUTURE: add a platform layer to the map so we could use for, eg, freebsd/macos/etc?As far I see there is no way other than fixing the version by setting I find it slightly unfortunate to not have a way to have this configurable, since there are so many options to influence ansible's use of python, but exactly this is missing, which makes is very hard to deal with the issue. |
|
it is configurable, (as you mention globally, by setting |
|
@boca, I think @sivel already tried to explain it and I can reproduce it as well: I could reproduce it on a SuSe v42.3 client-server having Python v2.7 and Python v3.4 installed at the same time (from the repositories), whilst running Ansible v2.12.2 on Rocky v9. I tried following w/o success:
In all of the four above mentioned variations I tried The only thing that did the trick, was the bodge of adapting ubuntu:
'14': /usr/bin/python
'16': /usr/bin/python3
suse:
'42': /usr/bin/python # Python2.7 is aliased to 'python` in Suse 42.3PS: Since I'm not sure, if adapting (fixing) the logic of the check itself may have some weird side-effects: What speaks against appending the |
|
@bcoca your argument depends on that you know in advance in your inventory, what server you are managing down to the OS version, at the time you are starting to use ansible. We for example have a highly complex environment, and I would rather not like to establish a database connection from my ansible host to our central ops DB, just so I can retrieve the OS Version to dynamically generate an inventory entry, just so I can set the interpreter. I personally worked around it by manually patching the There is already Ubuntu 14/16 in it, which I assume has a valid reason to it, and exactly because of these issues detailed above, it would be highly appreciated and reasonable to also include the specialized case of well-defined OS versions, where python 3 is in an unsupported / old version, but an usable version with python2.7 still exists... I personally believe not honoring |
|
I ran into a similar issue with Centos 6. The base.yml has this: which I believe is what Centos falls under. The system also has python2.7 in the path, but ansible looks at |
|
same issue if remote is suse12 |
Summary
After upgrading our Ansible server from Ubuntu 18.04 to 22.04 and reinstalling Ansible via PIP to the latest version we are now experiencing issues when running setup module (gather_facts) on a lot of hosts.
Ansible always attempts to use the discovered /usr/bin/python3 interpreter even if it is too old but the alternative python2 installation on the remote host is sufficient.
Here is an example error (from gather_facts stage):
These are the installed interpreters on a sample remote host that produces the error:
As you can see, the default /usr/bin/python is sufficient (v2.7.13) whereas /usr/bin/python3 is too old (v3.4.10).
I thought that interpreter_python = auto_legacy is supposed to try /usr/bin/python first?
Issue Type
Bug Report
Component Name
setup
Ansible Version
Configuration
OS / Environment
Target OS:
Many, but for the example above it's SLES 12.5.
Steps to Reproduce
ANSIBLE_DEBUG=1 ansible-playbook test.yml -vvvvvagainst a server that has python 2.7.13 (sufficient) and python 3.4.10 (too old) installed.Expected Results
Receive facts.
Actual Results
Code of Conduct
The text was updated successfully, but these errors were encountered: