Determine ramifications of migrating to Ansible 10.0

[artis3n]

Ansible 10.0 (released June 2024) deprecates support for Python 2.7 and 3.6, which breaks many of the older distros (#478 ) tested on this role, but are still supported by Tailscale. https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_10.html

Removed Python 2.7 and Python 3.6 as a supported remote version. Python 3.7+ is now required for target execution.

Have to figure out how we want to handle that inside this role. Eventually, we’ll probably need to release a major update that supports the latest version of Ansible which will require deprecating formal support for those distros from this role.

[artis3n]

I think this mostly only impacts the CI suite of this repo. Anyone installing this role can continue to use this role on Ansible 9.x, as long as we don’t adopt any 10.x-specific syntax (which to my knowledge doesn’t yet exist). But If I update this repo to use Ansible 10.x, then I cannot run tests against those older distros. So staying on Ansible 9.x, for a while at least, shouldn’t have any impact on end users.

Please let me know if I’m thinking about this wrong.

Distros broken on Ansible 10:

• Amazon Linux 2
• AlmaLinux 8
• Rocky Linux 8
• RHEL 8
• Oracle Linux 8
• Ubuntu 18.04
• OpenSUSE Leap (up to at least 15.6)
• CentOS 7

[artis3n]

This makes me kind of want a metrics capability in the role so I can collect the distribution of OS distros targeted by this role. What % of end users would this change impact?

[McSim85]

Those distros looks pretty old, but some of them are still under the vendor (extended, commercial) support. At least Ubuntu and RHEL.

https://access.redhat.com/support/policy/updates/errata#RHEL8_and_9_Life_Cycle

https://ubuntu.com/about/release-cycle

It’s a good practice to start with the “deprecation warning” message. T And then retire those distros, when the vendor lifecycle be retired.

Missing the CI tests sounds reasonable during the retirement period, thou