Unfortunately, if we upgrade ansible-core to 2.17, we cannot support Rocky Linux 8, openSUSE 15.5, RHEL 8, and Amazon Linux 2, which come with Python 3.6 pre-installed. However, the Managed node for ansible-core 2.17 requires Python 3.7 or higher.

ansible/ansible#83357

• openSUSE 15.5: 31 Dec 2024
• Amazon Linux 2: 30 Jun 2025
• RHEL 8: (Maintenance Support) 31 May 2029
• Rocky Linux 8: (Security EOL) 31 May 2029

Would it not be possible to allow 2.17.x as max version and still use 2.16 for the tests of those OS's

@NemesisRE Do you have a particular reason for updating the max version?

I wanted to use an ansible host without the need of an extra venv just for kubespray

if kubespray wants to be compatible with RHEL 8 and Rocky Linux 8 will it use ansible 9 until 2029?

I wanted to use an ansible host without the need of an extra venv just for kubespray

Your PR would lead other users to believe this can be used with ansible-core version 2.17. Ansible 9 is based on ansible-core 2.16 and does not specify whether it is compatible with 2.17.

Creating Virtualenv is the recommended method, as it does not interfere with the original system's default version of Python.

FYI: https://kubespray.io/#/docs/ansible/ansible

if kubespray wants to be compatible with RHEL 8 and Rocky Linux 8 will it use ansible 9 until 2029?

With the current information, unfortunately, Yes.

Unless there comes a time when we think it will be more difficult to maintain (10 years is not a short time), we will consider removing support for systems that come with Python 3.6 pre-installed.

so realistically we would need a matrix check to make sure the project is future proof

Ref: https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-community-changelogs

exactly that's what I ment

/lifecycle frozen

Hi @tico88612

If we use Conda to install the kubespray(not only the pip), would that resolve the issue?
Currently, some popular Python-based open-source projects are using similar approaches, such as

• VLLM https://docs.vllm.ai/en/stable/getting_started/installation.html
• PyTorch https://pytorch.org/get-started/locally/

This way, Kubespray would no longer depend on the Python version installed on the server, allowing for broader usage.

If we use Conda to install the kubespray(not only the pip), would that resolve the issue?

No, this is related to the remote host's Python pre-install version, not for the control host's.

We need to first upgrade the Python version of the remote host before the remote host can be controlled by the new version of Ansible.

If we use Conda to install the kubespray(not only the pip), would that resolve the issue?

No, this is related to the remote host's Python pre-install version, not for the control host's.

We need to first upgrade the Python version of the remote host before the remote host can be controlled by the new version of Ansible.

Got it, Thanks @tico88612 .

There is a similar issue for the openshift-ansible openshift/openshift-ansible@a6bd995 .
It fixes the ansible version for rhel 8

There is also a blog about that https://www.jeffgeerling.com/blog/2024/newer-versions-ansible-dont-work-rhel-8