Hi Thorsten,
On 25/09/2025 19:04, Thorsten Glaser wrote:
Hi Lee,
This is generally not supported, I've explained the rationale here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111137#10
I don't think we should deviate from the support matrix provides by upstream,
I understand the motivation. Extra link for others coming to this:
https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix
However, we cannot just upgrade the control node quite yet as there
are a handful buster systems still (working on upgrading these) and
even a few stretch systems (that may need to live a while longer),
which the bookworm ansible-core still supports.
as I expect a few dozen bugs when running against trixie hosts.
OK. This is the only one I’ve run into so far, and I solved it by
adding the two-line patch into the file in /usr locally.
It's easy to only notice one issue since there are so many modules to choose
from, and I typically only use a subset, too. If you however run the
autopkgtests against older releases you'll see a few dozen issues popping up.
I’ll take your info and rationale with me and we’ll be finding some
solution (perhaps something that skips running on old hosts if the
repo playbooks are run on the new control node, viceque versa; there
has to be something (I’m new to ansible) that makes this possible).
In this case I recommend installing older ansible versions in a virtual env or
chroot and running it against the older targets. The only challenge here is that
you have to ensure your playbooks run on all ansible versions you intend to support.
I believe some DDs working at Evolix ran into the same problem, maybe you can
reach out and ask them how they solved this.
Thanks,
//Thorsten
Hope I could help! o/
Greets,
Lee
