This shouldn't change the interpreter ultimately chosen by Ansible. It should
only improve the hit rate of performing interpreter discovery, particular in
cases where only pythonX.Y is present on the target.
Interpreter discovery may take longer or shorter, depending on the Ansible
version and the interpreters present on the target.
On my laptop his reduces the time to execute `ansible -mping ...` by approx
300 ms with `strategy=mitogen_linear`.
Until this commit Mitogen was unnecessarily sending large chunks of Ansible
from the controller to targets, due to `__main__` being identified as a
related module of `ansible.module_utils.basic`, and resolving to something
within `ansible.cli...`.
On Ansible target hosts executing any Ansible Module `__main__` is imported by
`ansible.module_utils.basic` as part of Ansible's module delivery mechanism.
When `mitogen.master.ModuleResponder` (on the controller) processes the
request for `ansible.module_utils.basic` from the target, it scans
`ansible.module_utils.basic` for related imports and finds `__main__`. However
`__main__` on the controller is not the same module as `__main__` on the
target. On the controller it is a module in `ansible.cli...` that implements
one of the ansible commands (e.g. `ansible`, `ansible-playbook`).
Only the Mitogen unit tests will run against CentOS 5, providing atleast some
Python 2.4test coverage. There is no version of Ansible that supports Python
2.4 that is also supported by Mitogen 0.3.
The SSH key exchange argument is to persuade newer SSH clients to talk with
such an old SSH server.
See https://www.openssh.org/legacy.html
Previously this test used a manually compiled list of results, which is
fragile and an ongoing maintenance burden. New method should 'just work' and
be more transparent.
This technique might be more widely applicable in the test suite.
centos8-test:2025.02 no longer has a /usr/bin/python installed, so use
centos8-py3 target which sets `ansible_python_interpreter=/usr/bin/python3` in
the templated inventory.
Ansible <= 9 (ansible-core <= 2.6) now discover the interpreter as
/usr/bin/python3 on debian11-test:2025.02, as opposed to
/usr/bin/python3.9 on debian11-test:2021. I'm don't know the exact
cause. From manual tests the change in observed behaviour appears to be common to
vanilla Ansible (strategy=linear) and Mitogen flavour
(strategy=mitogen_linear).
```console
(ans9) ➜ mitogen git:(4efb7158) ✗ ANSIBLE_STRATEGY=mitogen_linear ANSIBLE_STRATEGY_PLUGINS=ansible_mitogen/plugins/strategy ans9/bin/ansible -e ansible_python_interpreter=auto -mping d11.lan
d11.lan | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
(ans9) ➜ mitogen git:(4efb7158) ✗ ans9/bin/ansible -e ansible_python_interpreter=auto -mping d11.lan
d11.lan | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
```
Update some tests which assume `/usr/bin/python` exists or that `env python`
will resolve successfully.
It's not consistant across Ansible versions, particular the oldest ones. This
may have contributed to older test images containing usernames from the host
OS that they were built on (e.g. dmw, alex).
It was necessary to split setup.yml because there is no common subset of
supported include/import keywords across Ansible 2.3 - 2.11. The yaml stdout
callback is unavailabe in Ansible 2.3.
This eliminates use of third-party *-vault images and performs repository
config during image prep.
The Apache httpd proxy is necessary because https://vault.centos.org now only
accepts TLS 1.x connections, and CentOS 5 can only do upto SSL 3.0. It is
developed to run on Debian 11.
Alex Willmer