New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid the need for ansible_python_interpreter=python3 hack #45852

Open
ssbarnea opened this Issue Sep 19, 2018 · 6 comments

Comments

Projects
None yet
7 participants
@ssbarnea
Contributor

ssbarnea commented Sep 19, 2018

SUMMARY

At this moment, Ansible would fail to run on most remote hosts that do only have python3 installed by default, like Fedora 27 or newer, unless the user exclicitely adds the ansible_python_interpreter=python3 inside the inventory.

This is a real issue because it assumes that the user already knows which is the default ansible interpreter on that host, which may not be something he knows or even controls. Think about dynamic inventories or playbooks that would upgrade a host from a version that had python2 to one that that has python3.

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

core

ADDITIONAL INFORMATION

This issue was aggravated by the recommandation made https://www.python.org/dev/peps/pep-0394/ which indirectly made newer distributions which ship with python3 by default to not create a symlink from python to python3, even when there was no python2 installed.

As it seems highly unlikely to be able to update the PEP with new recomandations, we should look into findina solution for ansible, one that does not cripple the UX and avoids the need to tune ansible_python_interpreter variable for each host. This should happen under the hood by detecting a missing interpreter and falling back to python3 one (caching may be desired too).

Related links

@sivel

This comment has been minimized.

Member

sivel commented Sep 19, 2018

We have plans on adding functionality to address this in a future release. I believe there is another issue for it, but I cannot find it right now.

It is not yet on the roadmap, so I don't have a lot of details about it at this time, but it will likely be an optionally enabled step, run before gather_facts that would try to locate an acceptable python binary.

cc @nitzmahone

@abadger

This comment has been minimized.

Member

abadger commented Sep 19, 2018

#42767 and #42783

@ssbarnea

This comment has been minimized.

Contributor

ssbarnea commented Sep 19, 2018

These are really good news, I only hope that change would be backported two versions below or it will be too late for most people.

@nitzmahone

This comment has been minimized.

Member

nitzmahone commented Sep 19, 2018

Yeah, I think I'm owning getting this one ready during 2.8. I've already got a working prototype of the actual interpreter detection logic (a 2-step shell + Python-backed table lookup thing)- that's kind of the easy part. The harder parts are:

  1. performance - this should only run once per host, and ideally be cached across runs (with sane ways to clear the cached value, eg meta: flush_python_interpreter_cache or some such, plus a solution for adhoc)
  2. easing it in to avoid breaking people using /usr/bin/python on non-py2-by-default hosts

The way I'm currently thinking about it, it'll be a special config value for ansible_python_interpreter. Unfortunately, it's potentially a breaking change for anyone that's relying on the default /usr/bin/python on a system whose "default Python" isn't that (as the new autointerpreter stuff will use the system default Python in those cases). So during the first 2-4 releases, we'll probably config-default it to something like auto_warn, which will run the interpreter detection if ansible_python_interpreter hasn't been explicitly set as a host/groupvar, and emit a deprecation warning if /usr/bin/python is present but not what was detected; something like: "It appears that you're not using the default system Python (/path/to/system_python) on this host; in release X.Y, Ansible will default to this interpreter, so ensure the necessary Python dependencies for your modules are present in that interpreter's environment, or set ansible_python_interpreter=/usr/bin/python for this host to keep using the current interpreter". Users can explicitly set ansible_python_interpreter=auto to force the new behavior without the deprecation warning at any time, and once we've hit whatever deprecation threshold we decide on, we'll change the config default to auto.

Anyway, this is a very high priority for me to get in for 2.8 (and hopefully pretty early) so we can start the clock on making it the default behavior as soon as possible.

@jwflory

This comment has been minimized.

jwflory commented Sep 20, 2018

I'm looking forward to seeing this fixed! I've been hitting this issue on Fedora cloud images and wrote a blog post about it.

@ncoghlan

This comment has been minimized.

ncoghlan commented Nov 18, 2018

@nitzmahone is likely already aware of this, but the "no /usr/bin/python or /usr/bin/python3 by default" structure in the RHEL 8 beta adds the extra autodetection wrinkle of "platform-python vs user-facing-python2 vs user-facing-python3": https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment