#1111137 ansible-core: get_url fails connecting to remote Python 3.12+

#1111137#5
Date:
2025-08-15 01:16:26 UTC
From:
To:
Dear Maintainer,

I am attempting to use my ansible playbooks on an up-to-date bookworm
system to create a new trixie VM.  Several of the playbooks use get_url
to retrieve a URL's content on the remote system.

When I run one of those playbooks, I get

failed: [example.lan] (item={'url': 'https://example.org/some/path/foo.txt',
'dest': '/another/path/foo.txt'}) => {"ansible_loop_var": "item",
"changed": false, "dest": "/another/path/foo.txt", "elapsed": 0, "item":
{"dest": "/another/path/foo.txt", "url":
"https://example.org/some/path/foo.txt"}, "msg": "An unknown error
occurred: HTTPSConnection.__init__() got an unexpected keyword argument
'cert_file'", "url": "https://example.org/some/path/foo.txt"}

Doing some online searching (eg [1]) I belive the problem occurs because
the bookworm host system is passing 'cert_file' in Python executed on
the remote system, but the remote system has Python 3.12+ and
HTTPSConnection doesn't allow a 'cert_file' keyword. (Note that the play
doesn't have a cert_file option specified.)

My search ([1]) indicates the problem was fixed in ansible-core 2.16.0,
but bookworm is based on 2.14.18, and there's no bookworm-backport for
ansible.

Would it be possible to backport some version of the fix to bookworm?

[1] https://forum.ansible.com/t/unknown-error-httpsconnection-init/38811

#1111137#10
Date:
2025-08-15 12:55:13 UTC
From:
To:
Hi Ed,

Generally that is correct, and expected behaviour. ansible only supports python
version that existed at the release of the version. The support matrix is
available here:

https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix

You can see that ansible 2.14 does support python up to version 3.11, whereas
trixie has python 3.13.

If I'm wrong with the assumption that you're trying to run ansible 2.14 against
a trixie target, and instead both your controller and target are bookworm,
please provide a minimal reproducer.

I will generally not do that, since I expect a lot of 2.14 code to fail on
python 3.13, and I do not want to retroactively widen the support matrix that
upstream isn't even willing to support. As such, I'll tag this bug wontfix.
However, several alternatives exist:

Your options are either upgrading to trixie that ships ansible 2.19, which
supports python3.13 (but then again drops 2.7 support, so you need to check if
you have very old machines). Or installing ansible via pip in a virtual environment.

I might provide a backported ansible 2.19.1 for bookworm, but that will happen
earliest in a few weeks, after it has been released and the version in trixie is
updated.

Hope I could help!

Greets,
Lee

#1111137#15
Date:
2025-08-16 15:18:57 UTC
From:
To:
Oh, I wasn't aware of that.  I've previously always used the oldstable
version of ansible to recreate my VMs when a new stable version of
Debian was released.  I guess I just avoided breaking changes in Python
like the removal of the cert_file keyword argument between the Python
version in bookworm and the version in trixie.

Since my purpose is just to create new versions of my VMs based on
trixie, this will likely be the easiest solution, and one I hadn't
thought of.

I understand your reasoning for not fixing, so I'm OK with "wontfix".
Thanks for your time and a thorough list of my alternatives.

#1111137#24
Date:
2025-08-27 11:07:07 UTC
From:
To:
close 1111137
thanks

As discussed, closing the bug.