.zuul: update ansible-version to v11#1824
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the .zuul.yaml configuration to set ansible-version: 11 for a system test job. The review feedback points out that other jobs running on Fedora Rawhide should also be updated to use ansible-version: 11 to avoid Python 3.13 compatibility issues.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
674d32c to
bf7032d
Compare
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
|
recheck github blip |
|
recheck # Failed to cache image quay.io/toolbx/ubuntu-toolbox:20.04 to /var/tmp/bats-run-G8bcNa/suite/image-cache/ubuntu-toolbox-20.04 |
There was a problem hiding this comment.
Thanks for fixing and investigating this, @TristanCacqueray ! I am curious how ansible-version: 11 maps to ansible-core 2.18 so that I can handle similar issues myself without bothering you. :)
I found the documentation of a Zuul job, which mentions ansible-version. It says that 9 is the default and the other option is 11, and it doesn't say anything about the mapping. I found a few other pieces of documentation with similar results.
I tracked it down to the JobParser.fromYaml() method in Zuul's zuul/configloader.py, but I still can't find a mapping to the ansible-core version.
Oops! Just after submitting the review, I managed to coax Google/Gemini to teach me that the Ansible (community?) package version and the ansible-core version are different things. After some digging around, I found the Ansible 11 release notes, and the specific notes for v11.0.0 says: Ansible 11.0.0 contains ansible-core version 2.18.0. This is a newer version than version 2.17.0 contained in the previous Ansible release. I guess I answered my own question. :) |
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
debarshiray
left a comment
There was a problem hiding this comment.
While fiddling around with Ansible, I realized that I already have Python 3.13 on my old stable Fedora host, which got me curious about what's going on in Fedora Rawhide. :)
Some Git forensics brought me to this CPython commit for Python 3.15 about adding support for OpenSSL 4.0. A quick read of the commit was puzzling because this worked with all three of Fedora's python3.13, python3.14 and python3.15 packages on my old Fedora:
>>> import ssl
>>> ssl.PROTOCOL_TLSv1
Some head scratching later, I read the commit again and realized that only the use of OpenSSL 4.0, which I don't have on my host, removes ssl.PROTOCOL_TLSv1. This was reported downstream in Fedora, and is being tracked upstream at python/cpython#152709 and should be addressed by python/cpython#152714
This only affects Fedora Rawhide because of the Python3.15 and OpenSSL40 Changes.
The default Python stack in Fedora Rawhide was updated from version 3.14
to 3.15 [1], and OpenSSL 4.0 was introduced [2]. As a result of this
combination, the PROTOCOL_TLSv1 attribute disappeared from Python's ssl
module [3]. This prevents Zuul from working with Fedora Rawhide hosts,
because of this Ansible error:
TASK [add-build-sshkey : Enable access via build key on all nodes] ***
An exception occurred during task execution. To see the full
traceback, use -vvv.
The error was: AttributeError: module 'ssl' has no attribute
'PROTOCOL_TLSv1'. Did you mean '.PROTOCOL_TLS' instead of
'.PROTOCOL_TLSv1'?
The use of ssl.PROTOCOL_TLSv1 was removed from ansible-core 2.17.0 [4],
which became available in Ansible 10 [5]; and since Zuul 13.0.0, the
default Ansible version is 9, and version 11 can be optionally used.
Therefore, explicitly selecting Ansible 11 resolves this breakage when
the combination of Python 3.15 and OpenSSL 4.0 are used.
[1] https://fedoraproject.org/wiki/Changes/Python3.15
[2] https://fedoraproject.org/wiki/Changes/OpenSSL40
[3] CPython commit 3364e7e62fa24d0e
python/cpython@3364e7e62fa24d0e
python/cpython#146217
python/cpython#146207
[4] ansible-core commit 92d2c66db2eecd0f
ansible/ansible@92d2c66db2eecd0f
ansible/ansible#81880
[5] https://github.com/ansible-community/ansible-build-data/blob/main/10/CHANGELOG-v10.md
[6] https://zuul-ci.org/docs/zuul/latest/releasenotes.html
containers#1824
Signed-off-by: Tristan Cacqueray <tdecacqu@redhat.com>
bf7032d to
b935371
Compare
|
I took the liberty to update the Git commit message with a summary of my ramblings as a crutch for future forgetful me. :) Let's merge once the CI passes. In the meantime, I will go out for a walk. |
|
@debarshiray haa good catch, thank you for the details! For the version mapping, I used the wrong link in the commit message, I had too many tabs and I meant to paste: https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-community-changelogs <- this shows the mapping between ansible and ansible-core. |
|
recheck failed to load images when context deadline exceeded |
The default Python stack in Fedora Rawhide was updated from version 3.14
to 3.15 [1], and OpenSSL 4.0 was introduced [2]. As a result of this
combination, the PROTOCOL_TLSv1 attribute disappeared from Python's ssl
module [3]. This prevents Zuul from working with Fedora Rawhide hosts,
because of this Ansible error:
TASK [add-build-sshkey : Enable access via build key on all nodes] ***
An exception occurred during task execution. To see the full
traceback, use -vvv.
The error was: AttributeError: module 'ssl' has no attribute
'PROTOCOL_TLSv1'. Did you mean '.PROTOCOL_TLS' instead of
'.PROTOCOL_TLSv1'?
The use of ssl.PROTOCOL_TLSv1 was removed from ansible-core 2.17.0 [4],
which became available in Ansible 10 [5,6]; and since Zuul 13.0.0, the
default Ansible version is 9, and version 11 can be optionally used [7].
Therefore, explicitly selecting Ansible 11 resolves this breakage when
the combination of Python 3.15 and OpenSSL 4.0 are used.
[1] https://fedoraproject.org/wiki/Changes/Python3.15
[2] https://fedoraproject.org/wiki/Changes/OpenSSL40
[3] CPython commit 3364e7e62fa24d0e
python/cpython@3364e7e62fa24d0e
python/cpython#146217
python/cpython#146207
[4] ansible-core commit 92d2c66db2eecd0f
ansible/ansible@92d2c66db2eecd0f
ansible/ansible#81880
[5] https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html
[6] https://github.com/ansible-community/ansible-build-data/blob/main/10/CHANGELOG-v10.md
[7] https://zuul-ci.org/docs/zuul/latest/releasenotes.html
containers#1824
Signed-off-by: Tristan Cacqueray <tdecacqu@redhat.com>
b935371 to
93f882c
Compare
I see, cool. I included it in the commit message. |
This change bumps ansible-core to 2.18 which should support python3.13 to enable running jobs on rawhide.