Skip to content
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

Ansible+Mitogen ignores interpreter_python global variable #740

Open
jlu5 opened this issue Aug 30, 2020 · 9 comments · May be fixed by #833
Open

Ansible+Mitogen ignores interpreter_python global variable #740

jlu5 opened this issue Aug 30, 2020 · 9 comments · May be fixed by #833
Labels
bug Code feature that hinders desired execution outcome user-reported

Comments

@jlu5
Copy link

jlu5 commented Aug 30, 2020

Hello,

I'm running the Git version of Mitogen as of commit a60c6c1. It seems that after the changes in #658, Ansible+Mitogen respects the ansible_interpreter_python variable, but not the [defaults]/interpreter_python of ansible.cfg, as described in https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html#interpreter-discovery. Although this can be easily worked around, I do find the current behaviour a bit confusing.


I'm running ansible 2.9.9+dfsg-1 from Debian unstable on my host:

$ ansible --version
ansible 2.9.9
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/james/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.5 (default, Aug  2 2020, 15:09:07) [GCC 10.2.0]

The target machines run Debian 10 with Python 2.7.16 and 3.7.3 installed.

Expected behaviour (strategy=linear)

$ ansible staging -m setup -a 'filter=ansible_python_version'
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "3.7.3"
    },
    "changed": false
}
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "3.7.3"
    },
    "changed": false
}

Behaviour with strategy=mitogen_linear:

$ ansible staging -m setup -a 'filter=ansible_python_version'
[WARNING]: Platform linux on host redacted.hostname is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "2.7.16",
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false
}
[WARNING]: Platform linux on host redacted.hostname is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "2.7.16",
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false
}

Editted by @moreati: clarify variable vs config distinction.

@s1113950
Copy link
Collaborator

😱 oh no, I missed interpreter_python support when adding in #658 . Definitely a bug, not sure when I'll be able to get to this but it'll be fixed up at some point 👍 thanks for filing.

@sandinak
Copy link

sandinak commented Sep 10, 2020

As a note to this .. it also doesn't expand it if a jinja2 template is used .. which we do for venv ( ye $DIETY I wish ansible would support venv more natively!!! )

ansible_python_interpreter: "{{ lookup('env','ANSIBLE_HOME')}}/venv/bin/python"

Setting a relative path does work .. but that's not interchangable with the default strategy .. which wants a ful path.

@sandinak
Copy link

As a note to this .. it also doesn't expand it if a jinja2 template is used .. which we do for venv ( ye $DIETY I wish ansible would support venv more natively!!! )

ansible_python_interpreter: "{{ lookup('env','ANSIBLE_HOME')}}/venv/bin/python"

Setting a relative path does work .. but that's not interchangable with the default strategy .. which wants a ful path.

Just saw the PR in #658 now supported .. so ignore.

@dsgnr
Copy link

dsgnr commented Sep 22, 2020

Is there a timeline of when there will be a new release? I've tested against master branch and the discovery works in my tests, but I'm unable to use it till there is a new version released.

@s1113950
Copy link
Collaborator

A new release will happen after #715 lands. I had planned for it to be released a lot earlier but the tests are proving to be a pain... 😞 things that work locally fail in Azure DevOps for some reason. I reeeeally wanna release before the end of the month, and I will try to make that happen.

@s1113950
Copy link
Collaborator

It's not ideal but in the meantime you could peg to the current master hash of the repo in your pip install as a temporary workaround to a new release :)

@yoonsikp
Copy link

yoonsikp commented Nov 21, 2020

Best solution is to make a group_vars/all.yml for each of your inventories, with:

ansible_python_interpreter: /usr/bin/python3

@s1113950
Copy link
Collaborator

@dsgnr new rc tags have been made:
https://github.com/dw/mitogen/releases/tag/v0.2.10-rc.0 -> Ansible < 2.10
https://github.com/dw/mitogen/releases/tag/v0.3.0-rc.0 -> Ansible 2.10+
both tags have the fix (not interpreter_python, but ansible_interpreter_python). They're mostly ready, aside from a few edge cases that have been found (v0.3.0 specifically, 0.2.10 doesn't have these), and some changelogs

@dw dw added bug Code feature that hinders desired execution outcome user-reported labels Feb 2, 2021
@extmind extmind linked a pull request Apr 29, 2021 that will close this issue
@michaelw730
Copy link

Hi all,
the PR for this failed on a number of checks last year, is there anyway to re-run it or provide more information on the failure?
I've come across this issue with a playbook I'm running on various distros but suse12 is the only one that would need to use this setting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Code feature that hinders desired execution outcome user-reported
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants